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Executive  Summary 

In  2007-08,  we  began  an  investigation  of  problems,  issues,  and  opportunities  that  arise  during  the 
acquisition  of  software  systems  that  rely  on  open  architectures  and  open  source  software.  The  current 
effort  funded  for  2009  seeks  to  continue  and  build  on  the  results  in  this  area,  while  refining  its  focus  to 
center  on  the  essential  constraints  and  tradeoffs  we  have  identified  for  software-intensive  systems  with 
open  architecture  (OA)  and  continuously  evolving  open  source  software  (OSS)  elements.  The  U.S.  Air 
Force,  Army,  and  Navy  have  all  committed  to  an  open  technology  development  strategy  that 
encourages  the  acquisition  of  software  systems  whose  requirements  include  the  development  or 
composition  of  an  OA  for  such  systems,  and  the  use  of  OSS  systems,  components,  or  development 
processes  when  appropriate.  Our  goal  is  to  further  develop  and  document  foundations  for  emerging 
policy  and  guidance  for  acquiring  software  systems  that  require  OA  and  that  incorporate  OSS  elements. 
This  report  documents  and  describes  the  findings  and  results  that  we  have  produced  as  a  result  of  our 
research  into  the  area  of  the  acquisition  of  software  systems  that  rely  on  OA  and  OSS.  In  particular,  it 
includes  four  research  papers  that  have  been  refereed,  reviewed,  presented,  and  published  in  national 
and  international  research  conferences,  symposia,  and  workshops. 
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Research  Description 


OSS  is  an  integrated  web  of  people,  processes,  and  organizations,  including  project  teams 
operating  as  virtual  organizations  [Scacchi  2002,  2007].  There  is  a  basic  need  to  understand  how  to 
identify  an  optimal  mix  of  OSS  within  Open  Architectures  (OA)  as  products,  production  processes, 
practices,  community  activities,  and  multi-project  (or  multi-organization)  software  ecosystem. 
However,  the  relationship  among  OA,  OSS,  requirements,  and  acquisition  is  poorly  understood  [cf. 
Scacchi  2002,  Naegle  and  Petross  2007].  Subsequently,  in  2007-08,  we  began  by  examining  how 
different  OSS  licenses  can  encumber  software  systems  within  OA,  which  therefore  give  rise  to  new 
requirements  for  how  best  to  acquire  software-intensive  systems  with  OA  and  OSS  elements  [Scacchi 
and  Alspaugh  2008]. 

Across  the  three  military  services  within  the  DoD,  OA  means  different  things  and  is  seen  as  the 
basis  for  realizing  different  kinds  of  outcomes  [Justice  2007,  Navy  2007,  Riechers  2007].  Thus,  it  is 
unclear  whether  the  acquisition  of  a  software  system  that  is  required  to  incorporate  an  OA,  as  well  as 
utilize  OSS  technology  and  development  processes  [Wheeler  2007],  for  one  military  service  will 
realize  the  same  kinds  of  benefits  anticipated  for  OA-based  systems  by  another  service.  Somehow, 

DoD  acquisition  program  managers  must  make  sense  of  or  reconcile  such  differences  in  expectations 
and  outcomes  from  OA  strategies  in  each  service  and  across  DoD.  Yet  there  is  little  explicit  guidance 
or  reliance  on  systematic  empirical  studies  for  how  best  to  develop,  deploy,  and  sustain  complex 
software-intensive  military  systems  in  the  different  OA  and  OSS  presentations  and  documents  that 
have  so  far  been  disseminated  [Starrett  2007,  Weathersby  2007,  Wheeler  2007]. 

It  is  becoming  clear  that  verification  and  validation  (V&V)  is  a  crucial  activity  for  OSS  in  OA. 
Two  key  benefits  of  OSS  are  its  reliability  and  its  openness  to  rapid,  agile  evolution  in  response  to 
changing  needs.  Following  Justice  [2007],  we  envision  that  warfighters  will  be  not  only  users  of  OSS 
but  also  contributing  “developers”  to  it,  as  they  know  what  is  needed  "right  now"  to  give  them  the  edge 
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over  their  opponents  and  are  best  placed  to  translate  that  quickly  into  new  system  capabilities. 

However,  it  is  still  important  that  OSS/OA  systems  be  reliable  and  remain  open.  The  benefit  of  having 
a  new  feature  to  respond  to  a  current  threat  is  reduced  if  the  change  causes  a  needed  existing  feature  to 
stop  working,  or  in  the  worst  case  causes  the  system  to  fail  unexpectedly.  With  development  activities 
extended  out  close  to  "the  tip  of  the  spear"  it  is  also  necessary  to  extend  V&V  out  to  the  same 
developers  and  their  quick-response  development.  Not  only  do  they  need  to  be  able  to  quickly  validate 
the  changes  they  have  made,  they  also  need  to  be  able  to  do  quick,  highly  automated  regression  testing 
to  identify  any  existing  functions  that  the  new  changes  have  interfered  with.  At  the  same  time,  DoD 
needs  a  structure  for  managing  the  evolution  of  OSS  and  OA  systems  at  higher  levels,  to  deal  with  the 
decisions  of  which  "spear-tip"  changes  to  fold  into  the  system  for  larger  groups  of  users,  and  when,  and 
to  resolve  the  inevitable  conflicts  that  will  arise  as  different  groups  of  developers  take  the  system  in 
different,  sometimes  conflicting  directions.  In  addition,  verification  must  confirm  that  the  changed 
system  remains  open,  as  well  as  correct.  V&V  must  be  done  quickly  and  convincingly  at  these  broader 
levels  as  well,  and  will  be  important  in  supporting  decisions  about  which  modifications  to  disseminate 
when.  The  recent  work  Berzins  [2008]  presented  at  the  2008  Acquisition  Research  Symposium  shows  one 
approach  that  applies  a  high  degree  of  automation  in  order  to  make  regression  testing  more  efficient 
and  more  manageable  in  response  to  system  modifications. 

We  now  turn  to  address  the  problems  for  acquisition  research  in  this  area. 

Problem  for  Acquisition  Research 

OA  seems  to  imply  software  system  architectures  incorporating  OSS  components  and  open 
application  program  interfaces  (APIs).  But  not  all  software  system  architectures  incorporating  OSS 
components  and  open  APIs  will  produce  OA  [cf.  Scacchi  and  Alspaugh  2008],  since  OA  depends  on: 

(a)  how/why  OSS  and  open  APIs  are  located  within  the  system  architecture,  (b)  how  OSS  and  open 
APIs  are  implemented,  embedded,  or  interconnected,  (c)  whether  the  copyright  licenses  assigned  to 
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different  OSS  components  encumber  all/part  of  a  software  system's  architecture  into  which  they  are 
integrated.  Similarly,  (d)  alternative  architectural  configurations  and  APIs  for  a  given  system  may  or 
may  not  produce  an  OA.  Subsequently,  we  believe  this  can  lead  to  situations  in  which  if  program 
acquisition  stipulates  a  software-intensive  system  with  an  OA  and  OSS,  and  the  architectural  design  of 
a  system  constrains  system  requirements  (i.e.,  what  requirements  can  be  satisfied  by  a  given  system 
architecture,  or  given  system  requirements  what  architecture  is  implied),  then  the  resulting  software 
system  may  or  may  not  embody  an  OA. 

OSS  processes  encourage  users  (here,  warfighters)  to  become  contributing  developers,  and  in  an 
OA  context  this  entails  distributing  V&V  to  them  as  well.  A  traditional  approach  to  system  and 
component  requirements  may  or  may  not  support  OSS  components’  rapid  and  fluid  evolution,  and  the 
distributed,  efficient  V&V  that  will  be  needed  at  all  levels  from  system  down  to  components.  The  need 
to  manage  evolution  at  a  high  level  also  imposes  constraints  on  requirements  and,  quite  probably, 
architectures. 

Thus,  given  the  goal  of  realizing  an  OA  strategy,  together  with  the  use  of  evolving  OSS 
components  and  open  APIs,  how  should  program  acquisition,  system  requirements,  software  V&V, 
open  architectures,  and  post-deployment  system  support  be  aligned  to  achieve  this  goal?  As  such,  this 
is  the  central  research  problem  we  are  investigating  in  order  to  identify  principles,  best  practices,  and 
knowledge  for  how  best  to  insure  the  success  of  the  OA  strategy  when  OSS  and  open  APIs  are  required 
or  otherwise  employed.  Without  such  knowledge,  program  acquisition  managers  and  PEOs  are  unlikely 
to  acquire  software-intensive  systems  that  will  result  in  an  OA  that  is  clean,  robust  and  transparent. 

This  may  frustrate  the  ability  of  program  managers  or  PEOs  to  realize  faster,  better,  and  cheaper 
software  acquisition,  development,  and  post-deployment  support. 

Issues  for  Acquisition  Research 

Based  on  current  research  into  the  acquisition  of  OA  systems  with  OSS  components  [Scacchi 
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and  Alspaugh  2008],  this  research  project  investigated  the  following  kinds  of  research  questions:  How 
does  the  interaction  of  requirements  and  architectures  for  OA  systems  incorporating  OSS  components 
facilitate  or  inhibit  acquisition  practices  over  time?  What  are  the  best  available  ways  and  means  for 
continuously  verifying  and  validating  the  functionality,  correctness,  and  openness  of  OA  when  OSS 
components  are  employed?  How  do  OA  systems  evolve  over  time  when  incorporating  continuously 
improving  OSS  components?  How  can  use  of  continuously  evolving  OSS  in  OA  be  combined  with  the 
need  to  verify  and  validate  critical  systems  and  to  manage  their  evolution?  How  do  reliability  and 
predictability  trade-off  against  the  cost  and  flexibility  of  an  OA  system  when  incorporating  OSS 
components?  How  should  OA  software  systems  be  developed  and  deployed  to  support  warfighter 
modification  in  the  field  or  participation  in  post-deployment  system  support,  when  OSS  components 
are  employed? 

Prospects  for  longer-term  Acquisition-related  research 

Each  of  the  military  services  has  committed  to  orienting  their  major  system  acquisition 
programs  around  the  adoption  of  an  OA  strategy  that  in  turn  embraces  and  encourages  the  adoption, 
development,  use,  and  evolution  of  OSS.  Thus,  it  would  seem  there  is  a  significant  need  for  sustained 
research  that  investigates  the  interplay  and  inter-relationships  between  (a)  current/emerging  guidelines 
for  the  acquisition  of  software-intensive  systems  within  the  DoD  community,  and  (b)  how  software 
systems  that  employ  an  OA  incorporating  OSS  products  and  production  processes  are  essential  to 
improving  the  effectiveness  of  future,  software-intensive  program  acquisition  efforts. 

Findings  and  Results 

Based  on  the  research  studies  conducted  during  this  project  during  the  2009  project  year,  we 
produced  a  series  of  four  papers  that  have  been  reviewed  and  refereed  by  software  engineering,  open 
source  software,  open  architecture,  and  acquisition  researchers.  Each  of  these  papers  has  been  jointly 
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authored  by  the  members  of  our  project  team,  Walt  Scacchi,  Thomas  Alspaugh,  and  Hazel  Asuncion, 
and  each  has  been  presented  at  top-tier  international  research  conferences,  national  symposia,  or 
workshops,  and  all  have  been  published.  Thus,  we  are  reasonably  confident  about  the  quality  and 
nature  of  our  findings,  as  well  as  to  the  veracity  of  the  research  approach  we  have  pursued,  and  the 
computational  tools  and  analytical  methods  we  have  employed  along  the  way.  Furthermore,  we  are 
continuing  to  build  on  these  results  during  the  next  annual  cycle  of  research  beginning  in  2010. 

Our  first  paper,  “Software  Licenses,  Open  Source  Components,  and  Open  Architectures,” 
appears  in  Proc.  6th.  Annual  Acquisition  Research  Symposium,  Monterey,  CA,  May  2009.  This  paper 
lays  the  foundation  for  our  approach  and  direction  for  problems  to  investigate,  as  are  documented  in  the 
remaining  three  papers.  It  was  presented  and  well  received  at  the  ARS,  and  received  many  favorable 
comments  from  members  of  the  Acquisition  community  in  attendance. 

Our  second  paper,  “Analyzing  Software  Licenses  in  Open  Architecture  Software 
Systems,”  Proc.  Workshop  on  Emerging  Trends  in  FLOSS  Research  and  Development,  Intern.  Conf. 
Software  Engineering,  Vancouver,  Canada,  May  2009.  This  paper  represents  findings  that  are  framed 
to  specifically  address  the  relationship  between  OA,  OSS,  and  software  licenses,  which  subsequently 
became  part  of  the  core  of  the  doctoral  dissertation  of  our  project  team  member,  Hazel  Asuncion.  This 
effort  was  expanded  in  much  great  detail,  as  shown  in  her  dissertation  [Asuncion  2009],  and 
documented  on  her  research  seminar  held  at  the  Institute  for  Software  Research  in  June  2009.  See 
http://www.ics.uci.edu/~hasuncio/assets/ISR09_License.pdf. 

Our  third  paper,  “Intellectual  Property  Rights  Requirements  for  Heterogeneously  Licensed 
Systems”  in  Proc.  17th.  Intern.  Conf.  Requirements  Engineering  (RE09),  Atlanta,  GA,  24-33, 
September  2009,  likely  represents  the  major  research  results  to  date  during  the  2009  project  period. 

This  study  introduces  the  formal  logic  scheme  we  developed  to  specify  heterogeneous  OA  software 
licenses  in  a  form  that  can  subsequently  be  analyzed  using  the  computational  tools  and  techniques 
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developed  by  Asuncion  [2009].  In  this  regard,  this  study  demonstrates  the  viability  of  our  approach  to 
be  able  to  verify  and  validate  the  rights  and  obligations  associated  with  different  software  licenses  that 
are  found  in  complex  OA  with  OSS  system  components.  Furthermore,  the  study  demonstrates  that  this 
approach  can  be  applied  to  OA  at  different  stages  in  the  development  and  deployment,  thus  increasing 
the  value  of  the  approach  and  its  potential  contribution. 

Our  fourth  and  last  paper,  “The  Role  of  Software  Licenses  in  Open  Architecture 
Ecosystems,”  Intern.  Workshop  on  Software  Ecosystems,  Intern.  Conf.  Software  Reuse,  Falls  Church, 
VA,  September  2009,  demonstrates  how  our  approach  can  be  further  extended  to  address  the  analysis 
of  software  licenses  challenges  across  the  supply  chain  of  commercial  and  governmental  software 
system  contractors  and  customers.  This  also  increases  the  value  of  the  approach  and  its  potential 
contribution. 

Final  Remarks 

Each  of  the  four  research  papers  that  constitute  the  bulk  of  our  project  deliverables  follow  in  the 
remaining  parts  of  this  report.  We  welcome  the  opportunity  to  respond  to  any  questions  or  comments 
following  from  our  research  efforts,  along  with  a  willingness  to  describe  our  view  of  how  these  results 
can  be  applied  to  future  open  architecture  systems  that  contain  software  system  components  that  may 
include  those  subject  to  different,  possibly  conflicting,  open  source  software  licenses. 
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Abstract 

A  substantial  number  of  enterprises  and  independ¬ 
ent  software  vendors  are  adopting  a  strategy’  in  which 
software-intensive  systems  are  developed  with  an  open 
architecture  (OA)  that  may  contain  open  source  soft¬ 
ware  (OSS)  components  or  components  with  open 
APIs.  The  emerging  challenge  is  to  realize  the  benefits 
of  openness  when  components  are  subject  to  different 
copyright  or  property  licenses.  In  this  paper  we  iden¬ 
tify  key  properties  of  OSS  licenses,  present  a  license 
analysis  scheme  to  identify  license  conflicts  arising 
from  composed  software  elements,  and  apply  it  to  pro¬ 
vide  guidance  for  software  architectural  design 
choices  whose  goal  is  to  enable  specific  licensed  com¬ 
ponent  configurations.  Our  scheme  has  been  imple¬ 
mented  in  an  operational  environment  and  demon¬ 
strates  a  practical,  automated  solution  to  the  problem 
of  determining  overall  rights  and  obligations  for  alter¬ 
native  OAs. 

1.  Introduction 

It  has  been  common  for  OSS  projects  to  require  that 
developers  contribute  their  work  under  conditions  that 
ensure  the  project  can  license  its  products  under  a  spe¬ 
cific  OSS  license.  For  example,  the  Apache  Contribu¬ 
tor  License  Agreement  grants  enough  rights  to  the 
Apache  Software  Foundation  for  the  foundation  to 
license  the  resulting  systems  under  the  Apache  Li¬ 
cense.  This  sort  of  license  configuration,  in  which  the 
rights  to  a  system’s  components  are  homogenously 
granted  and  the  system  has  a  well-defined  OSS  license, 
was  the  norm  and  continues  to  this  day. 

Flowever,  we  more  and  more  commonly  see  a  dif¬ 
ferent  license  configuration,  in  which  the  components 
of  a  system  do  not  have  the  same  license.  The  resulting 
system  may  not  have  any  recognized  OSS  license  at 
all — in  fact,  our  research  indicates  this  is  the  most 


likely  outcome — but  instead,  if  all  goes  well  in  its  de¬ 
sign,  there  will  be  enough  rights  available  in  the  sys¬ 
tem  so  that  it  can  be  used  and  distributed,  and  perhaps 
modified  by  others  and  sublicensed,  if  the  correspond¬ 
ing  obligations  are  met.  These  obligations  are  likely  to 
differ  for  components  with  different  licenses;  a  BSD 
(Berkeley  Software  Distribution)  licensed  component 
must  preserve  its  copyright  notices  when  made  part  of 
the  system,  for  example,  while  the  source  code  for  a 
modified  component  covered  by  MPL  (the  Mozilla 
Public  License)  must  be  made  public,  and  a  component 
with  a  reciprocal  license  such  as  the  Free  Software 
Foundation’s  GPL  (General  Public  License)  might 
carry  the  obligation  to  distribute  the  source  code  of 
that  component  but  also  of  other  components  that  con¬ 
stitute  “a  whole  which  is  a  work  based  on”  the  GPL’d 
component.  The  obligations  may  conflict,  as  when  a 
GPL’d  component’s  reciprocal  obligation  to  publish 
source  code  of  other  components  is  combined  with  a 
proprietary  license’s  prohibition  of  publishing  source 
code,  in  which  case  there  may  be  no  rights  available 
for  the  system  as  a  whole,  not  even  the  right  of  use, 
because  the  obligations  of  the  licenses  that  would  per¬ 
mit  use  of  its  components  cannot  simultaneously  be 
met. 

The  central  problem  we  examine  and  explain  in  this 
paper  is  to  identify  principles  of  software  architecture 
and  software  licenses  that  facilitate  or  inhibit  success 
of  the  OA  strategy  when  OSS  and  other  software  com¬ 
ponents  with  open  APIs  are  employed.  This  is  the 
knowledge  we  seek  to  develop  and  deliver.  Without 
such  knowledge,  it  is  unlikely  that  an  OA  that  is  clean, 
robust,  transparent,  and  extensible  can  be  readily  pro¬ 
duced.  On  a  broader  scale,  this  paper  seeks  to  explore 
and  answer  the  following  kinds  of  research  questions: 

•  What  license  applies  to  an  OA  system  composed 
with  components  with  different  licenses? 

•  How  do  alternative  OSS  licenses  facilitate  or  in¬ 
hibit  the  development  of  OA  systems? 
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•  How  should  software  license  constraints  be  speci¬ 
fied  so  it  is  possible  to  automatically  determine  the 
overall  set  of  rights  and  obligations  associated 
with  a  configured  software  system  architecture? 

This  paper  may  help  establish  a  foundation  for  how 
to  analyze  and  evaluate  dependencies  that  might  arise 
when  seeking  to  develop  software  systems  that  em¬ 
body  an  OA  when  different  types  of  software  compo¬ 
nents  or  software  licenses  are  being  considered  for 
integration  into  an  overall  system  configuration. 

In  the  remainder  of  this  paper,  we  examine  software 
licensing  constraints.  This  is  followed  by  an  analysis 
of  how  these  constraints  can  interact  in  order  to  deter¬ 
mine  the  overall  license  constraints  applicable  to  the 
configured  system  architecture.  Next,  we  describe  an 
operational  environment  that  demonstrates  automatic 
determination  of  license  constraints  associated  with  a 
configured  system  architecture,  and  thus  offers  a  solu¬ 
tion  to  the  problem  we  face.  We  close  with  a  discus¬ 
sion  of  the  conclusions  that  follow. 

2.  Background 

There  is  little  explicit  guidance  or  reliance  on  sys¬ 
tematic  empirical  studies  for  how  best  to  develop,  de¬ 
ploy,  and  sustain  complex  software  systems  when  dif¬ 
ferent  OA  and  OSS  objectives  are  at  hand.  Instead,  we 
find  narratives  that  provide  ample  motivation  and  be¬ 
lief  in  the  promise  and  potential  of  OA  and  OSS  with¬ 
out  consideration  of  what  challenges  may  lie  ahead  in 
realizing  OA  and  OSS  strategies.  Ven  [2008]  is  a  re¬ 
cent  exception. 

We  believe  that  a  primary  challenge  to  be  addressed 
is  how  to  determine  whether  a  system,  composed  of 
subsystems  and  components  each  with  specific  OSS  or 
proprietary  licenses,  and  integrated  in  the  system’s 
planned  configuration,  is  or  is  not  open,  and  what  li¬ 
cense  constraints  apply  to  the  configured  system  as  a 
whole.  This  challenge  comprises  not  only  evaluating 
an  existing  system  at  run-time,  but  also  at  design-time 
and  build-time  for  a  proposed  system  to  ensure  that  the 
result  is  “open”  under  the  desired  definition,  and  that 
only  the  acceptable  licenses  apply;  and  also  under¬ 
standing  which  licenses  are  acceptable  in  this  context. 
Because  there  are  a  range  of  types  and  variants  of  li¬ 
censes  [cf.  OSI  2008],  each  of  which  may  affect  a  sys¬ 
tem  in  different  ways,  and  because  there  are  a  number 
of  different  kinds  of  OSS-related  components  and 
ways  of  combining  them  that  affect  the  licensing  issue, 
a  first  necessary  step  is  to  understand  the  kinds  of 
software  elements  that  constitute  a  software  architec¬ 
ture,  and  what  kinds  of  licenses  may  encumber  these 
elements  or  their  overall  configuration. 


OA  seems  to  simply  mean  software  system  archi¬ 
tectures  incorporating  OSS  components  and  open  ap¬ 
plication  program  interfaces  (APIs).  But  not  all  soft¬ 
ware  system  architectures  incorporating  OSS  compo¬ 
nents  and  open  APIs  will  produce  an  OA,  since  the 
openness  of  an  OA  depends  on:  (a)  how/why  OSS  and 
open  APIs  are  located  within  the  system  architecture, 
(b)  how  OSS  and  open  APIs  are  implemented,  embed¬ 
ded,  or  interconnected,  (c)  whether  the  copyright  (In¬ 
tellectual  Property)  licenses  assigned  to  different  OSS 
components  encumber  all/part  of  a  software  system's 
architecture  into  which  they  are  integrated,  and  (d)  the 
fact  that  many  alternative  architectural  configurations 
and  APIs  exist  that  may  or  may  not  produce  an  OA  [cf. 
Anton  and  Alspaugh  2007,  Scacchi  and  Alspaugh 
2008].  Subsequently,  we  believe  this  can  lead  to  situa¬ 
tions  in  which  new  software  development  or  acquisi¬ 
tion  requirements  stipulate  a  software  system  with  an 
OA  and  OSS,  but  the  resulting  software  system  may  or 
may  not  embody  an  OA.  This  can  occur  when  the  ar¬ 
chitectural  design  of  a  system  constrains  system  re¬ 
quirements — raising  the  question  of  what  requirements 
can  be  satisfied  by  a  given  system  architecture,  when 
requirements  stipulate  specific  types  or  instances  of 
OSS  (e.g.,  Web  browsers,  content  management  serv¬ 
ers)  to  be  employed,  or  what  architecture  style  [Bass, 
Clements,  and  Kazman  2003]  is  implied  by  a  given  set 
of  system  requirements. 

Thus,  given  the  goal  of  realizing  an  OA  and  OSS 
strategy  together  with  the  use  of  OSS  components  and 
open  APIs,  it  is  unclear  how  to  best  align  acquisition, 
system  requirements,  software  architectures,  and  OSS 
elements  across  different  software  license  regimes  to 
achieve  this  goal  [Scacchi  and  Alspaugh  2008]. 

3,  Understanding  open  architectures 

The  statement  that  a  system  is  intended  to  embody 
an  open  architecture  using  open  software  technologies 
like  OSS  and  APIs,  does  not  clearly  indicate  what  pos¬ 
sible  mix  of  software  elements  may  be  configured  into 
such  a  system.  To  help  explain  this,  we  first  identify 
what  kinds  of  software  elements  are  included  in  com¬ 
mon  software  architectures  whether  they  are  open  or 
closed  [cf.  Bass,  Clements,  Kazman  2003]. 

1.  Software  source  code  components  -  (a)  standalone 
programs,  (b)  libraries,  frameworks,  or  middle¬ 
ware,  (c)  inter-application  script  code  (e.g.,  C  shell 
scripts)  and  (d)  intra-application  script  code  (e.g., 
to  create  Rich  Internet  Applications  using  domain- 
specific  languages  (e.g.,  XUL  for  Firefox  Web 
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browser  [Feldt  2007]  or  “mashups”  [Nelson  and 
Churchill  2006]). 

2.  Executable  components  —  These  are  programs  for 
which  the  software  is  in  binary  form,  and  its 
source  code  may  not  be  open  for  access,  review, 
modification,  and  possible  redistribution.  Execu¬ 
table  binaries  can  be  viewed  as  “derived  works” 
[Rosen  2005]. 

3.  Application  program  interfaces/APIs  -  The  avail¬ 
ability  of  externally  visible  and  accessible  APIs  to 
which  independently  developed  components  can 
be  connected  is  the  minimum  condition  required 
to  form  an  “open  system”  [Meyers  and  Obendorf 
2001], 

4.  Software  connectors  -  In  addition  to  APIs,  these 
may  be  software  either  from  libraries,  frameworks, 
or  application  script  code  whose  intended  purpose 
is  to  provide  a  standard  or  reusable  way  of  associ¬ 
ating  programs,  data  repositories,  or  remote  ser¬ 
vices  through  common  interfaces.  The  High  Level 
Architecture  (HLA)  is  an  example  of  a  software 
connector  scheme  [Kuhl,  Weatherly,  Damann 
2000],  as  are  CORBA,  Microsoft's  .NET,  Enter¬ 
prise  Java  Beans,  and  LGPL  libraries. 

5.  Configured  system  or  sub-system  architectures  - 
These  are  software  systems  that  can  be  built  to 
conform  to  an  explicit  architectural  design.  They 
include  software  source  code  components,  execu¬ 
table  components,  APIs,  and  connectors  that  are 
organized  in  a  way  that  may  conform  to  a  known 
“architectural  style”  such  as  the  Representational 
State  Transfer  [Fielding  and  Taylor  2002]  for 
Web-based  client-server  applications,  or  may  rep¬ 
resent  an  original  or  ad  hoc  architectural  pattern 
[Bass  2003].  Each  of  the  software  elements,  and 
the  pattern  in  which  they  are  arranged  and  inter¬ 
linked,  can  all  be  specified,  analyzed,  and  docu¬ 
mented  using  an  Architecture  Description  Lan¬ 
guage  and  ADL-based  support  tools  [Bass  2003, 
Medvidovic  1999]. 

Figure  1  provides  an  overall  view  of  an  archetypal 
software  architecture  for  a  configured  system  that  in¬ 
cludes  and  identifies  each  of  the  software  elements 
above,  as  well  as  including  free/open  source  software 
(e.g.,  Gnome  Evolution)  and  closed  source  software 
(WordPerfect)  components.  In  simple  terms,  the  con¬ 
figured  system  consists  of  software  components  (grey 
boxes  in  the  Figure)  that  include  a  Mozilla  Web 
browser,  Gnome  Evolution  email  client,  and  WordPer¬ 
fect  word  processor,  all  running  on  a  Linux  operating 
system  that  can  access  file,  print,  and  other  remote 
networked  servers  (e.g.  an  Apache  Web  server).  These 
components  are  interrelated  through  a  set  of  software 


connectors  (ellipses  in  the  Figure)  that  connect  the 
interfaces  of  software  components  (small  white  boxes 
attached  to  a  component)  and  link  them  together.  Mod¬ 
ern  day  enterprise  systems  or  command  and  control 
systems  will  generally  have  more  complex  architec¬ 
tures  and  a  more  diverse  mix  of  software  components 
than  shown  in  the  figure  here.  As  we  examine  next, 
even  this  simple  architecture  raises  a  number  of  OSS 
licensing  issues  that  constrain  the  extent  of  openness 
that  may  be  realized  in  a  configured  OA. 


Figure  1.  An  archetypal  software  architecture 
depicting  components  (grey  boxes),  connec¬ 
tors  (ellipses),  interfaces  (small  boxes  on 
components),  and  data/control  links 

4.  Understanding  open  software  licenses 

A  particularly  knotty  challenge  is  the  problem  of  li¬ 
censes  in  OSS  and  OA.  There  are  a  number  of  differ¬ 
ent  OSS  licenses,  and  their  number  continues  to  grow. 
Each  license  stipulates  different  constraints  attached  to 
software  components  that  bear  it.  External  references 
are  available  which  describe  and  explain  many  differ¬ 
ent  licenses  that  are  now  in  use  with  OSS  [Fontana 
2008,  OSI 2008,  Rosen  2005,  St.  Laurent  2004], 

More  and  more  software  systems  are  designed, 
built,  released,  and  distributed  as  OAs  composed  of 
components  from  different  sources,  some  proprietary 
and  others  not.  Systems  include  components  that  are 
statically  bound  or  interconnected  at  build-time,  while 
other  components  may  only  be  dynamically  linked  for 
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execution  at  run-time,  and  thus  might  not  be  included 
as  part  of  a  software  release  or  distribution.  Software 
components  in  such  systems  evolve  not  only  by  ongo¬ 
ing  maintenance,  but  also  by  architectural  refactoring, 
alternative  component  interconnections,  and  compo¬ 
nent  replacement  (via  maintenance  patches,  installation 
of  new  versions,  or  migration  to  new  technologies). 
Software  components  in  such  systems  may  be  subject 
to  different  software  licenses,  and  later  versions  of  a 
component  may  be  subject  to  different  licenses  (e.g., 
from  CDDL  (Sun’s  Common  Development  and  Distri¬ 
bution  License)  to  GPL,  or  from  GPLv2  to  GPLv3). 

Software  systems  with  open  architectures  are  sub¬ 
ject  to  different  software  licenses  than  may  be  common 
with  traditional  proprietary,  closed  source  systems 
from  a  single  vendor.  Software  architects/developers 
must  increasingly  attend  to  how  they  design,  develop, 
and  deploy  software  systems  that  may  be  subject  to 
multiple,  possibly  conflicting  software  licenses.  We 
see  architects,  developers,  software  acquisition  manag¬ 
ers,  and  others  concerned  with  OAs  as  falling  into 
three  groups.  The  first  group  pays  little  or  no  heed  to 
license  conflicts  and  obligations;  they  simply  focus  on 
the  other  goals  of  the  system.  Those  in  the  second 
group  have  assets  and  resources,  and  to  protect  these 
they  may  have  an  army  of  lawyers  to  advise  them  on 
license  issues  and  other  potential  vulnerabilities;  or 
they  may  constrain  the  design  of  their  systems  so  that 
only  a  small  number  of  software  licenses  (possibly  just 
one)  are  involved,  excluding  components  with  other 
licenses  independent  of  whether  such  components  rep¬ 
resent  a  more  effective  or  more  efficient  solution.  The 
third  group  falls  between  these  two  extremes;  members 
of  this  group  want  to  design,  develop,  and  distribute 
the  best  systems  possible,  while  respecting  the  con¬ 
straints  associated  with  different  software  component 
licenses.  Their  goal  is  a  configured  OA  system  that 
meets  all  its  goals,  and  for  which  all  the  license  obliga¬ 
tions  for  the  needed  copyright  rights  are  satisfied.  It  is 
this  third  group  that  needs  the  guidance  the  present 
work  seeks  to  provide. 

There  has  been  an  explosion  in  the  number,  type, 
and  variants  of  software  licenses,  especially  with  open 
source  software  (cf.  OSI  2008).  Software  components 
are  now  available  subject  to  licenses  such  as  the  Gen¬ 
eral  Public  License  (GPL),  Mozilla  Public  License 
(MPL),  Apache  Public  License,  (APL),  Academic  li¬ 
censes  (e.g.,  BSD,  MIT),  Creative  Commons,  Artistic, 
and  others  as  well  as  Public  Domain  (either  via  explicit 
declaration  or  by  expiration  of  prior  copyright  license). 
Furthermore,  licenses  such  as  these  can  evolve,  result¬ 
ing  in  new  license  versions  over  time.  But  no  matter 
their  diversity,  software  licenses  represent  a  legally 
enforceable  contract  that  is  recognized  by  government 


agencies,  corporate  enterprises,  individuals,  and  judi¬ 
cial  courts,  and  thus  they  cannot  be  taken  trivially.  As 
a  consequence,  software  licenses  constrain  open  archi¬ 
tectures,  and  thus  architectural  design  decisions. 

So  how  might  we  support  the  diverse  needs  of  dif¬ 
ferent  software  developers,  with  respect  to  their  need 
to  design,  develop,  and  deploy  configured  software 
systems  with  different,  possibly  conflicting  licenses  for 
the  software  components  they  employ?  Is  it  possible  to 
provide  automated  means  for  helping  software  devel¬ 
opers  determine  what  constraints  will  result  at  design¬ 
time,  build-time,  or  run-time  when  their  configured 
system  architectures  employ  diverse  licensed  compo¬ 
nents?  These  are  the  kind  of  questions  we  address  in 
this  paper. 

4.1.  Software  licenses:  Rights  and  obligations 

Copyright,  the  common  basis  for  software  licenses, 
gives  the  original  author  of  a  work  certain  exclusive 
rights,  which  for  software  include  the  right  to  use, 
copy,  modify,  merge,  publication,  distribution,  sub¬ 
licensing,  and  sell  copies.  These  rights  may  be  licensed 
to  others;  the  rights  may  be  licensed  individually  or  in 
groups,  and  either  exclusively  so  that  no  one  else  can 
exercise  them  or  (more  commonly)  non-exclusively. 
After  a  period  of  years,  the  rights  enter  the  public  do¬ 
main,  but  until  then  the  only  way  for  anyone  other  than 
the  author  to  have  any  of  the  copyright  rights  is  to  li¬ 
cense  them. 

Licenses  may  impose  obligations  that  must  be  met 
in  order  for  the  licensee  to  realize  the  assigned  rights. 
Commonly  cited  obligations  include  the  obligation  to 
buy  a  legal  copy  to  use  and  not  distribute  copies  (pro¬ 
prietary  licenses);  the  obligation  to  preserve  copyright 
and  license  notices  (academic  licenses);  the  obligation 
to  publish  at  no  cost  source  code  you  modify  (MPL); 
or  the  reciprocal  obligation  to  publish  all  source  code 
included  at  build-time  or  statically  linked  (GPL). 

Licenses  may  provide  for  the  creation  of  derivative 
works  (e.g.,  a  transformation  or  adaptation  of  existing 
software)  or  collective  works  (e.g.,  a  Linux  distribu¬ 
tion  that  combines  software  from  many  independent 
sources)  from  the  original  work,  by  granting  those 
rights  possibly  with  corresponding  obligations. 

In  addition,  the  author  of  an  original  work  can  make 
it  available  under  more  than  one  license,  enabling  the 
work’s  distribution  to  different  audiences  with  differ¬ 
ent  needs.  For  example,  one  licensee  might  be  happy  to 
pay  a  license  fee  in  order  to  be  able  to  distribute  the 
work  as  part  of  a  proprietary  product  whose  source 
code  is  not  published,  while  another  might  need  to 
license  the  work  under  MPL  rather  than  GPL  in  order 
to  have  consistent  licensing  across  a  system.  Thus  we 
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now  see  software  distributed  under  any  one  of  several 
licenses,  with  the  licensee  choosing  from  two  (“dual 
license”)  or  three  (Mozilla’s  “tri-license”)  licenses. 

The  basic  relationship  between  software  license 
rights  and  obligations  can  be  summarized  as  follows:  if 
you  meet  the  specified  obligations,  then  you  get  the 
specified  rights.  So,  informally,  for  the  academic  li¬ 
censes,  if  you  retain  the  copyright  notice,  list  of  license 
conditions,  and  disclaimer,  then  you  can  use,  modify, 
merge,  sub-license,  etc.  For  MPL,  if  you  publish  modi¬ 
fied  source  code  and  sub-licensed  derived  works  under 
MPL,  then  you  get  all  the  MPL  rights.  And  so  forth  for 
other  licenses.  However,  one  thing  we  have  learned 
from  our  efforts  to  carefully  analyze  and  lay  out  the 
obligations  and  rights  pertaining  to  each  license  is  that 
license  details  are  difficult  to  comprehend  and  track — 
it  is  easy  to  get  confused  or  make  mistakes.  Some  of 
the  OSS  licenses  were  written  by  developers,  and  often 
these  turn  out  to  be  incomplete  and  legally  ambiguous; 
others,  usually  more  recent,  were  written  by  lawyers, 
and  are  more  exact  and  complete  but  can  be  difficult 
for  non-lawyers  to  grasp.  The  challenge  is  multiplied 
when  dealing  with  configured  system  architectures  that 
compose  multiple  components  with  heterogeneous 
licenses,  so  that  the  need  for  legal  interpretations  be¬ 
gins  to  seem  inevitable  [cf.  Fontana  2008,  Rosen 
2005].  Therefore,  one  of  our  goals  is  to  make  it  possi¬ 
ble  to  architect  software  systems  of  heterogeneously- 
licensed  components  without  necessarily  consulting 
legal  counsel.  Similarly,  such  a  goal  is  best  realized 
with  automated  support  that  can  help  architects  under¬ 
stand  design  choices  across  components  with  different 
licenses,  and  that  can  provide  support  for  testing  build¬ 
time  releases  and  run-time  distributions  to  make  sure 
they  achieve  the  specified  rights  by  satisfying  the  cor¬ 
responding  obligations. 

4.2.  Expressing  software  licenses 

Historically,  most  software  systems,  including  OSS 
systems,  were  entirely  under  a  single  software  license. 
However,  we  now  see  more  and  more  software  sys¬ 
tems  being  proposed,  built,  or  distributed  with  compo¬ 
nents  that  are  under  various  licenses.  Such  systems 
may  no  longer  be  covered  by  a  single  license,  unless 
such  a  licensing  constraint  is  stipulated  at  design-time, 
and  enforced  at  build-time  and  run-time.  But  when 
components  with  different  licenses  are  to  be  included 
at  build-time,  their  respective  licenses  might  either  be 
consistent  or  conflict.  Further,  if  designed  systems 
include  components  with  conflicting  licenses,  then  one 
or  more  of  the  conflicting  components  must  be  ex¬ 
cluded  in  the  build-time  release  or  must  be  abstracted 
behind  an  open  API  or  middleware,  with  users  re¬ 


quired  to  download  and  install  to  enable  the  intended 
operation.  (This  is  common  in  Linux  distributions  sub¬ 
ject  to  GPL,  where  for  example  users  may  choose  to 
acquire  and  install  proprietary  run-time  components, 
like  proprietary  media  players).  So  a  component  li¬ 
cense  conflict  need  not  be  a  show-stopper  if  identified 
at  design  time.  However,  developers  have  to  be  able  to 
determine  which  components’  licenses  conflict  and  to 
take  appropriate  steps  at  design,  build,  and  run  times, 
consistent  with  the  different  concerns  and  requirements 
that  apply  at  each  phase  [cf.  Scacchi  and  Alspaugh 
2008], 

In  order  to  fulfill  our  goals,  we  need  a  scheme  for 
expressing  software  licenses  that  is  more  formal  and 
less  ambiguous  than  natural  language,  and  that  allows 
us  to  identify  conflicts  arising  from  the  various  rights 
and  obligations  pertaining  to  two  or  more  component’s 
licenses.  We  considered  relatively  complex  structures 
(such  as  Hohfeld’s  eight  fundamental  jural  relations 
[Hohfeld  1913])  but,  applying  Occam’s  razor,  selected 
a  simpler  structure.  We  start  with  a  tuple  <actor,  op¬ 
eration,  action,  object>  for  expressing  a  right  or  obli¬ 
gation.  The  actor  is  the  “licensee”  for  all  the  licenses 
we  have  examined.  The  operation  is  one  of  the  follow¬ 
ing:  “may”,  “must”,  or  “must  not”,  with  “may”  ex¬ 
pressing  a  right  and  “must”  and  “must  not”  expressing 
obligations;  following  Hohfeld,  the  lack  of  a  right 
(which  would  be  “may  not”)  correlates  with  a  duty  to 
not  exercise  the  right  (“must  not”),  and  whenever  lack 
of  a  right  seemed  significant  in  a  license  we  expressed 
it  as  a  negative  obligation  with  “must  not”.  The  action 
is  a  verb  or  verb  phrase  describing  what  may,  must,  or 
must  not  be  done,  with  the  object  completing  the  de¬ 
scription.  We  specify  an  object  separately  from  the 
action  in  order  to  minimize  the  set  of  actions.  A  license 
then  may  be  expressed  as  a  set  of  rights,  with  each 
right  associated  (in  that  license)  with  zero  or  more  ob¬ 
ligations  that  must  be  fulfilled  in  order  to  enjoy  that 
right.  Figure  2  displays  the  tuples  and  associations  for 
two  of  the  rights  and  their  associated  obligations  for 
the  academic  BSD  software  license.  Note  that  the  first 
right  is  granted  without  corresponding  obligations. 


cUcensee,  may,  use,  the  binary  form  of  COMPONENTS  | 

cUcensee,  may,  redistribute,  derived  or  collective  works  in  binary  form  of  COMPONENTS  | 

\^^|<Licensee.  must,  retain,  copyright  notices  in  the  binary  form  of  COMPONENTS  | 

<Licensee.  must,  retain,  the  BSD  conditions  in  the  binary  form  of  COMPONENTS 


Figure  2.  A  portion  of  the  BSD  license  tuples 

We  now  turn  to  examine  how  OA  software  systems 
that  include  components  with  different  licenses  can  be 
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designed  and  analyzed  while  effectively  tracking  their 
rights  and  obligations. 

When  designing  an  OA  software  system,  there  are 
heuristics  that  can  be  employed  to  enable  architectural 
design  choices  that  might  otherwise  be  excluded  due  to 
license  conflicts.  First,  it  is  possible  to  employ  a  “li¬ 
cense  firewall”  which  serves  to  limit  the  scope  of  re¬ 
ciprocal  obligations.  Rather  than  simply  interconnect¬ 
ing  conflicting  components  through  static  linking  of 
components  at  build  time,  such  components  can  be 
logically  connected  via  dynamic  links,  client-server 
protocols,  license  shims  (e.g.,  via  LGPL  connectors), 
or  run-time  plug-ins.  Second,  the  source  code  of  stati¬ 
cally  linked  OSS  components  must  be  made  public. 
Third,  it  is  necessary  to  include  appropriate  notices  and 
publish  required  sources  when  academic  licenses  are 
employed.  However,  even  using  design  heuristics  such 
as  these  (and  there  are  many),  keeping  track  of  license 
rights  and  obligations  across  components  that  are  in¬ 
terconnected  in  complex  OAs  quickly  become  too 
cumbersome.  Thus,  automated  support  needs  to  be 
provided  to  help  overcome  and  manage  the  multi- 
component,  multi-license  complexity. 

5.  Automating  analysis  of  software  license 
rights  and  obligation 

We  find  that  if  we  start  from  a  formal  specification 
of  a  software  system’s  architecture,  then  we  can  asso¬ 
ciate  software  license  attributes  with  the  system’s  com¬ 
ponents,  connectors,  and  sub-system  architectures  and 
calculate  the  copyright  rights  and  obligations  for  the 
system.  Accordingly,  we  employ  an  architectural  de¬ 
scription  language  specified  in  xADL  [2005]  to  de¬ 
scribe  OAs  that  can  be  designed  and  analyzed  with  a 
software  architecture  design  environment  [Medvidovic 
1999],  such  as  ArchStudio4  [2006].  We  have  taken 
this  environment  and  extended  it  with  a  Software  Ar¬ 
chitecture  License  Traceability  Analysis  module  [cf. 
Asuncion  2008].  This  allows  for  the  specification  of 
licenses  as  a  list  of  attributes  (license  tuples)  using  a 
form-based  user  interface,  similar  to  those  already  used 
and  known  for  ArchStudio4  and  xADL  [ArchStudio 
2006,  Medvidovic  1999]. 

Figure  3  shows  a  screenshot  of  an  ArchStudio4  ses¬ 
sion  in  which  we  have  modeled  the  OA  seen  in  Fig¬ 
ure  1 .  OA  software  components,  each  of  which  has  an 
associated  license,  are  indicated  by  darker  shaded 
boxes.  Light  shaded  boxes  indicate  connectors.  Archi¬ 
tectural  connectors  may  or  may  not  have  associated 
license  information;  those  with  licenses  (such  as  archi¬ 
tectural  connectors  that  represent  functional  code)  are 
treated  as  components  during  license  traceability 


analysis.  A  directed  line  segment  indicates  a  link. 
Links  connect  interfaces  between  the  components  and 
connectors.  Furthermore,  the  Mozilla  component  as 
shown  here  contains  a  hypothetical  subarchitecture  for 
modeling  the  role  of  intra-application  scripting,  as 
might  be  useful  in  specifying  license  constraints  for 
Rich  Internet  Applications.  This  subarchitecture  is 
specified  in  the  same  manner  as  the  overall  system 
architecture,  and  is  visible  in  Figure  5.  The  automated 
environment  allows  for  tracing  and  analysis  of  license 
attributes  and  conflicts. 

Figure  4  shows  a  view  of  the  internal  XML  repre¬ 
sentation  of  a  software  license.  Analysis  and  calcula¬ 
tions  of  rights,  obligations,  and  conflicts  for  the  OA 
are  done  in  this  form.  This  schematic  representation  is 
similar  in  spirit  to  that  used  for  specifying  and  analyz¬ 
ing  privacy  and  security  regulations  associated  with 
certain  software  systems  [Breaux  and  Anton  2008]. 

With  this  basis  to  build  on,  it  is  now  possible  to 
analyze  the  alignment  of  rights  and  obligations  for  the 
overall  system: 

1.  Propagation  of  reciprocal  obligations 

Reciprocal  obligations  are  imposed  by  the  li¬ 
cense  of  a  GPL’d  component  on  any  other  com¬ 
ponent  that  is  part  of  the  same  “work  based  on  the 
Program”  (i.e.  on  the  first  component),  as  defined 
in  GPL.  We  follow  the  widely-accepted  interpreta¬ 
tion  that  build-time  static  linkage  propagate  the 
reciprocal  obligations,  but  the  “license  firewalls” 
do  not.  Analysis  begins,  therefore,  by  propagating 
these  obligations  along  all  connectors  that  are  not 
license  firewalls. 

2.  Obligation  conflicts 

An  obligation  can  conflict  with  another  obliga¬ 
tion  contrary  to  it,  or  with  the  set  of  available 
rights,  by  requiring  a  copyright  right  that  has  not 
been  granted.  For  instance,  the  Corel  proprietary 
license  for  the  WordPerfect  component,  CTL 
(Corel  Transactional  License),  may  be  taken  to  en¬ 
tail  that  a  licensee  must  not  redistribute  source 
code.  However,  an  OSS  license,  GPL,  may  state 
that  a  licensee  must  redistribute  source  code. 
Thus,  the  conflict  appears  in  the  modality  of  the 
two  otherwise  identical  obligations,  “must  not”  in 
CTL  and  “must”  in  GPL.  A  conflict  on  the  same 
point  could  occur  also  between  GPL  and  a  com¬ 
ponent  whose  license  fails  to  grant  the  right  to  dis¬ 
tribute  its  source  code. 

This  phase  of  the  analysis  is  affected  by  the 
overall  set  of  rights  that  are  required.  If  conflicts 
arise  involving  the  union  of  all  obligations  in  all 
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components’  licenses,  it  may  be  possible  to  elimi¬ 
nate  some  conflicts  by  selecting  a  smaller  set  of 
rights,  in  which  case  only  the  obligations  for  those 
rights  need  be  considered. 

Figure  5  shows  a  screenshot  in  which  the  Li¬ 
cense  Traceability  Analysis  module  has  identified 
obligation  conflicts  between  the  licenses  of  two 
pairs  of  components  (“WordPerfect”  and  “Linux 
OS”,  and  “GUIDisplayManager”  and  “GUIScript- 
Interpreter”). 

3.  Rights  and  obligations  calculations 

The  rights  available  for  the  entire  system  (use, 
copy,  modify,  etc.)  then  are  calculated  as  the  inter¬ 
section  of  the  sets  of  rights  available  for  each 
component  of  the  system. 

The  obligations  required  for  the  whole  system 
then  are  the  union  of  the  specific  obligations  for 
each  component  that  are  associated  with  those 
rights.  Examples  of  specific  obligations  are  “Li¬ 
censee  must  retain  copyright  notices  in  the  binary 
form  of  module  .  c”  or  “Licensee  must  publish 
the  source  code  of  component .  j  ava  version 
1.2. 3.” 

Figure  6  shows  a  report  of  the  calculations  for  the 
hypothetical  subarchitecture  of  the  Mozilla  component 
in  our  archetypal  architecture,  exhibiting  an  obligation 
conflict  and  the  single  copyright  right  (to  run  the  sys¬ 
tem)  that  the  prototype  tool  shows  would  be  available 
for  the  subarchitecture  as  a  whole  if  the  conflict  is  re¬ 
solved;  a  production  tool  would  also  list  the  rights 
(none)  currently  available. 

If  a  conflict  is  found  involving  the  obligations  and 
rights  of  linked  components,  it  is  possible  for  the  sys¬ 
tem  architect  to  consider  an  alternative  linking  scheme, 
employing  one  or  more  connectors  along  the  paths 
between  the  components  that  act  as  a  license  firewall, 
thereby  mitigating  or  neutralizing  the  component- 
component  license  conflict.  This  means  that  the  archi¬ 
tecture  and  the  environment  together  can  determine 
what  OA  design  best  meets  the  problem  at  hand  with 
available  software  components.  Components  with  con¬ 
flicting  licenses  do  not  need  to  be  arbitrarily  excluded, 
but  instead  may  expand  the  range  of  possible  architec¬ 
tural  alternatives  if  the  architect  seeks  such  flexibility 
and  choice. 

At  build-time  (and  later  at  run-time),  many  of  the 
obligations  can  be  tested  and  verified,  for  example  that 
the  binaries  contain  the  appropriate  notices  for  their 
licenses,  and  that  the  source  files  are  present  in  the 
correct  version  on  the  Web.  These  tests  can  be  gener¬ 
ated  from  the  internal  list  of  obligations  and  run  auto¬ 


matically.  If  the  system’s  interface  were  extended  to 
add  a  control  for  it,  the  tests  could  be  run  by  a  de¬ 
ployed  system. 

The  prototype  License  Traceability  Analysis  mod¬ 
ule  provides  a  proof-of-concept  for  this  approach.  We 
encoded  the  core  provisions  of  four  licenses  in  XML 
for  the  tool — GPL,  MPL,  CTL,  and  AFL  (Academic 
Free  License) — to  examine  the  effectiveness  of  the 
license  tuple  encoding  and  the  calculations  based  upon 
it.  While  it  is  clear  that  we  could  use  a  more  complex 
and  expressive  structure  for  encoding  licenses,  in  en¬ 
coding  the  license  provisions  to  date  we  found  that  the 
tuple  representation  was  more  expressive  than  needed; 
for  example,  the  actor  was  always  “licensee”  and 
seems  likely  to  remain  so,  and  we  found  use  for  only 
three  operations  or  modalities.  At  this  writing,  the 
module  shows  proof  of  concept  for  calculating  with 
reciprocal  obligations  by  propagating  them  to  adjacent 
statically-linked  modules;  the  extension  to  all  paths  not 
blocked  by  license  firewalls  is  straightforward  and  is 
independent  of  the  scheme  and  calculations  described 
here.  Reciprocal  obligations  are  identified  in  the  tool 
by  lookup  in  a  table,  and  the  meaning  and  scope  of 
reciprocality  is  hard-coded;  this  is  not  ideal,  but  we 
considered  it  acceptable  since  the  legal  definition  in 
terms  of  the  reciprocal  licenses  will  not  change  fre¬ 
quently.  We  also  focused  on  the  design-time  analysis 
and  calculation  rather  than  build-  or  run-time  as  it  in¬ 
volves  the  widest  range  of  issues,  including  representa¬ 
tions,  rights  and  obligations  calculations,  and  design 
guidance  derived  from  them. 

Based  on  our  analysis  approach,  it  appears  that  the 
questions  of  what  license  (if  any)  covers  a  specific 
configured  system,  and  what  rights  are  available  for 
the  overall  system  (and  what  obligations  are  needed  for 
them)  are  difficult  to  answer  without  automated  li¬ 
cense-architecture  analysis.  This  is  especially  true  if 
the  system  or  sub-system  is  already  in  operational  run¬ 
time  form  [cf.  Kazman  and  Carriere  1999].  It  might 
make  distribution  of  a  composite  OA  system  somewhat 
problematic  if  people  cannot  understand  what  rights  or 
obligations  are  associated  with  it.  We  offer  the  follow¬ 
ing  considerations  to  help  make  this  clear.  For  exam¬ 
ple,  a  Mozilla/Firefox  Web  browser  covered  by  the 
MPL  (or  GPL  or  LGPL,  in  accordance  with  the 
Mozilla  Tri-License)  may  download  and  run  intra¬ 
application  script  code  that  is  covered  by  a  different 
license.  If  this  script  code  is  only  invoked  via  dynamic 
run-time  linkage,  or  via  a  client-server  transaction  pro¬ 
tocol,  then  there  is  no  propagation  of  license  rights  or 
obligations.  However,  if  the  script  code  is  integrated 
into  the  source  code  of  the  Web  browser  as  persistent 
part  of  an  application  (e.g.,  as  a  plug-in),  then  it  could 
be  viewed  as  a  configured  sub-system  that  may  need  to 


15 


be  accessed  for  license  transfer  or  conflict  implica¬ 
tions.  Another  different  kind  of  example  can  be  antici¬ 
pated  with  application  programs  (like  Web  browsers, 
email  clients,  and  word  processors)  that  employ  Rich 
Internet  Applications  or  mashups  entailing  the  use  of 
content  (e.g.,  textual  character  fonts  or  geographic 
maps)  that  is  subject  to  copyright  protection,  if  the 
content  is  embedded  in  and  bundled  with  the  scripted 
application  sub-system.  In  such  a  case,  the  licenses 
involved  may  not  be  limited  to  OSS  or  proprietary 
software  licenses. 

In  the  end,  it  becomes  clear  that  it  is  possible  to 
automatically  determine  what  rights  or  obligations  are 
associated  with  a  given  system  architecture  at  design¬ 
time,  and  whether  it  contains  any  license  conflicts  that 
might  prevent  proper  access  or  use  at  build-time  or 
run-time,  given  an  approach  such  as  ours. 

6.  Discussion 

Software  system  configurations  in  OAs  are  intended 
to  be  adapted  to  incorporate  new  innovative  software 
technologies  that  are  not  yet  available.  These  system 
configurations  will  evolve  and  be  refactored  over  time 
at  ever  increasing  rates  [Scacchi  2007],  components 
will  be  patched  and  upgraded  (perhaps  with  new  li¬ 
cense  constraints),  and  inter-component  connections 
will  be  rewired  or  remediated  with  new  connector 
types.  As  such,  sustaining  the  openness  of  a  configured 
software  system  will  become  part  of  ongoing  system 
support,  analysis,  and  validation.  This  in  turn  may  re¬ 
quire  ADLs  to  include  OSS  licensing  properties  on 
components,  connectors,  and  overall  system  configura¬ 
tion,  as  well  as  in  appropriate  analysis  tools  [cf.  Bass, 
Clements,  and  Kazman2003,  Medvidovic  1999]. 

Constructing  these  descriptions  is  an  incremental 
addition  to  the  development  of  the  architectural  design, 
or  alternative  architectural  designs.  But  it  is  still  time- 
consuming,  and  may  present  a  somewhat  daunting 
challenge  for  large  pre-existing  systems  that  were  not 
originally  modeled  in  our  environment. 

Advances  in  the  identification  and  extraction  of 
configured  software  elements  at  build  time,  and  their 
restructuring  into  architectural  descriptions  is  becom¬ 
ing  an  ever  more  automatable  endeavor  [cf.  Choi  1990, 
Kazman  1999,  Jansen  2008].  Further  advances  in  such 
efforts  have  the  potential  to  automatically  produce 
architectural  descriptions  that  can  either  be  manually 
or  semi-automatically  annotated  with  their  license  con¬ 
straints,  and  thus  enable  automated  construction  and 
assessment  of  build-time  software  system  architec¬ 
tures. 


The  list  of  recognized  OSS  licenses  is  long  and 
ever-growing,  and  as  existing  licenses  are  tested  in  the 
courts  we  can  expect  their  interpretations  to  be  clari¬ 
fied  and  perhaps  altered;  the  GPL  definition  of  ‘‘work 
based  on  the  Program”,  for  example,  may  eventually 
be  clarified  in  this  way,  possibly  refining  the  scope  of 
reciprocal  obligations.  Our  expressions  of  license 
rights  and  obligations  are  for  the  most  part  compared 
for  identical  actors,  actions,  and  objects,  then  by  look¬ 
ing  for  “must  not”  in  one  and  either  “must”  or  “may” 
in  the  other,  so  that  new  licenses  may  be  added  by 
keeping  equivalent  rights  or  obligations  expressed 
equivalently.  Reciprocal  obligations,  however,  are 
handled  specially  by  hard-coded  algorithms  to  traverse 
the  scope  of  that  obligation,  so  that  addition  of  obliga¬ 
tions  with  different  scope,  or  the  revision  of  the  under¬ 
standing  of  the  scope  of  an  existing  obligation,  re¬ 
quires  development  work.  Possibly  these  issues  will 
be  clarified  as  we  add  more  licenses  to  the  tool  and 
experiment  with  their  application  in  OA  contexts. 

Lastly,  our  scheme  for  specifying  software  licenses 
offers  the  potential  for  the  creation  of  shared  reposito¬ 
ries  where  these  licenses  can  be  accessed,  studied, 
compared,  modified,  and  redistributed. 

7.  Conclusion 

The  relationship  between  open  architecture,  open 
source  software,  and  multiple  software  licenses  is 
poorly  understood.  OSS  is  often  viewed  as  primarily  a 
source  for  low-cost/ free  software  systems  or  software 
components.  Thus,  given  the  goal  of  realizing  an  OA 
strategy  together  with  the  use  of  OSS  components  and 
open  APIs,  it  has  been  unclear  how  to  best  align  soft¬ 
ware  architecture,  OSS,  and  software  license  regimes 
to  achieve  this  goal.  Subsequently,  the  central  problem 
we  examined  in  this  paper  was  to  identify  principles  of 
software  architecture  and  software  copyright  licenses 
that  facilitate  or  inhibit  how  best  to  insure  the  success 
of  an  OA  strategy  when  OSS  and  open  APIs  are  re¬ 
quired  or  otherwise  employed.  In  turn,  we  presented  an 
analysis  scheme  and  operational  environment  that 
demonstrates  that  an  automated  solution  to  this  prob¬ 
lem  exists. 

We  have  developed  and  demonstrated  an  opera¬ 
tional  environment  that  can  automatically  determine 
the  overall  license  rights,  obligations,  and  constraints 
associated  with  a  configured  system  architecture 
whose  components  may  have  different  software  li¬ 
censes.  Such  an  environment  requires  the  annotation  of 
the  participating  software  elements  with  their  corre¬ 
sponding  licenses.  These  annotated  software  architec¬ 
tural  descriptions  can  be  prescriptively  analyzed  at 
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design-time  as  we  have  shown,  or  descriptively  ana¬ 
lyzed  at  build-time  or  run-time.  Such  a  solution  offers 
the  potential  for  practical  support  in  design-,  build-, 
and  run-time  license  conformance  checking  and  the 
ever-more  complex  problem  of  developing  large  soft¬ 
ware  systems  from  configurations  of  software  elements 
that  can  evolve  over  time. 
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Figure  3.  An  ArchStudio  4  model  of  the  open  software  architecture  of  Figure  1 


Figure  4.  A  view  of  the  internal  schematic  representation  of  the  Mozila  Public  License 
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Figure  5.  License  conflicts  have  been  identified  between  two  pairs  of  components 
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ArchStudio  4  [Eclipse  Application]  C:\Program  Files\Java\jre  1.6. 0_05\bin\javaw.exe  (Sep  4,  2008  7:17:19  PM)  _ 


,5  License  Report  for  SubArchitecture :  MoZilla  SubArch 
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obligation:  CTL2  licensee  must  not  redistribute  source  code 
£  obligation:  CTL3 . 1  licensee  must  satisfy  CTL  terms,  conditions,  and  EULA 
obligation:  CTL2  licensee  must  purchase  license  for  the  SOFTWARE 
obligation:  GPL2  licensee  must  redistribute  source  code 
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Figure  6.  A  report  identifying  the  obligations,  conflicts,  and  rights  for  the  architectural  model 
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Abstract 

A  substantial  number  of  enterprises  and  independ¬ 
ent  software  vendors  are  adopting  a  strategy’  in  which 
software-intensive  systems  are  developed  with  an  open 
architecture  (OA)  that  may  contain  open  source  soft¬ 
ware  (OSS)  components  or  components  with  open 
APIs.  The  emerging  challenge  is  to  realize  the  benefits 
of  openness  when  components  are  subject  to  different 
copyright  or  property  licenses.  In  this  position  paper, 
we  identify  key’  properties  of  OSS  licenses,  present  a 
license  analysis  scheme,  and  discuss  our  approach  for 
automatically  analyzing  license  interactions. 

1.  Introduction 

Open  architectures  have  generally  referred  to  the 
ability  to  use  third  party  components  to  create  a  soft¬ 
ware  system.  Oreizy  uses  the  term  to  refer  to  his  cus¬ 
tomization  technique  of  making  the  architecture  model 
an  explicit  and  malleable  part  of  the  deployed  system 
[16],  while  the  Department  of  Defense  community  uses 
the  term  to  refer  to  guidelines  on  acquiring  and  com¬ 
posing  third  party  components  into  a  software  system 
[18].  Today,  we  see  more  and  more  software-intensive 
systems  developed  using  an  OA  strategy  not  only  with 
open  source  software  (OSS)  components  but  also  pro¬ 
prietary  components  with  open  APIs  (e.g.  [20]).  De¬ 
veloping  systems  using  the  OA  technique  can  lower 
development  costs  [18].  Composing  a  system  with 
heterogeneously-licensed  components,  however,  in¬ 
creases  the  likelihood  of  liabilities  stemming  from  in¬ 
compatible  licenses.  Thus,  in  this  paper,  we  define  an 
OA  system  as  a  software  system  consisting  of  compo¬ 
nents  that  are  either  open  source  or  proprietary  with 
open  API,  whose  overall  system  rights  at  a  minimum 
allow  its  use  and  redistribution. 

OA  systems  were  formerly  composed  solely  of  ho¬ 
mogenously-licensed  OSS  components.  These  OSS 
projects  have  commonly  required  developers  to  con¬ 


tribute  their  work  under  conditions  that  ensure  the  pro¬ 
ject  can  license  its  products  under  a  specific  OSS  li¬ 
cense.  This  is  changing,  however.  More  systems  are 
being  composed  of  software  components  associated 
with  different  licenses.  The  resulting  system  may  not 
have  any  recognized  OSS  license  at  all — but  if  the  sys¬ 
tem  is  designed  well  and  if  the  corresponding  obliga¬ 
tions  are  met,  copyright  rights  may  be  available  to  al¬ 
low  its  redistribution  and  sublicensing. 

Due  to  the  sheer  number  of  license  types,  variants, 
versions,  and  the  various  stipulations  attached  to  each 
of  these  licenses,  analyzing  the  compatibility  or  lack 
thereof  between  the  various  licenses  in  a  system  is  ex¬ 
tremely  difficult.  Licenses  are  often  incomplete  or 
hard  to  understand.  Licenses  are  also  legally  binding. 

Thus,  we  aim  to  identify  principles  of  software  ar¬ 
chitecture  and  software  licenses  that  facilitate  success 
of  an  OA  system.  We  present  a  systematic  approach  to 
analyzing  license  interaction  within  a  system  using  a 
formal  license  model  that  can  adequately  express  the 
majority  of  current  license  types.  We  then  incorporate 
this  model  into  xADL,  an  extensible  architecture  de¬ 
scription  language  that  rigorously  represents  a  software 
system  [10].  We  discuss  our  automated  support  for 
analyzing  licenses  within  ArchStudio4  [11]. 

2.  Background 

There  is  little  explicit  guidance  on  how  best  to  de¬ 
velop,  deploy,  and  sustain  complex  software  systems 
when  different  OA  and  OSS  objectives  are  at  hand. 
Ven  [21]  and  German  [8]  are  recent  exceptions. 

OA  may  simply  seem  to  mean  software  system  ar¬ 
chitectures  incorporating  OSS  components  and  open 
application  program  interfaces  (APIs).  But  not  all 
software  system  architectures  incorporating  OSS  com¬ 
ponents  and  open  APIs  will  produce  an  OA,  since  the 
available  license  rights  of  an  OA  depend  on:  (a) 
how/why  OSS  and  open  APIs  are  located  within  the 
system  architecture,  (b)  how  OSS  and  open  APIs  are 
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implemented,  embedded,  or  interconnected,  (c) 
whether  the  licenses  of  different  OSS  components  en¬ 
cumber  all/part  of  a  software  system's  architecture  into 
which  they  are  integrated,  and  (d)  the  fact  that  many 
alternative  architectural  configurations  and  APIs  exist 
that  may  or  may  not  produce  an  OA  system  (cf.  [3, 
18]).  Thus,  new  software  development  or  acquisition 
requirements  may  stipulate  a  software  system  with  an 
OA  and  OSS,  but  the  resulting  system  may  or  may  not 
have  the  rights  needed  to  embody  an  OA  system. 

3.  Understanding  open  architectures 

Stating  that  an  OA  system  comprises  OSS  and  open 
API  components  does  not  clearly  indicate  what  possi¬ 
ble  mixes  of  software  elements  may  be  configured  into 
such  a  system.  To  help  explain  this,  we  first  identify 
software  elements  included  in  common  software  archi¬ 
tectures  that  affect  whether  they  are  open  or  closed  [5], 

Software  source  code  components  -  These  can  be 
either  (a)  standalone  programs,  (b)  libraries,  frame¬ 
works,  or  middleware,  (c)  inter-application  script  code 
(e.g.,  C  shell  scripts)  and  (d)  intra-application  script 
code  (e.g.,  to  create  Rich  Internet  Applications  using 
domain-specific  languages  such  as  XUL  for  Firefox 
Web  browser  [6]  or  “mashups”  [15]). 

Executable  components  —  These  are  programs  in 
binary  form,  and  its  source  code  may  not  be  open  for 
access,  review,  modification,  and  possible  redistribu¬ 
tion.  Executable  binaries  are  a  compilation  of  source 
code  and  they  can  be  viewed  as  “derived  works”  [17]. 

Application  program  interfaces/APIs  -  The  avail¬ 
ability  of  externally  visible  and  accessible  APIs  is  the 
minimum  requirement  to  form  an  “open  system”  [14]. 

Software  connectors  -  Software  intended  to  pro¬ 
vide  a  standard  or  reusable  way  of  communication 
through  common  interfaces,  e.g.  High  Level  Architec¬ 
ture  (HLA)  [12],  CORBA,  MS  .NET,  and  GNU  Lesser 
General  Public  License  (LGPL)  libraries. 

Configured  system  or  sub-system  architectures  - 
These  are  software  systems  which  may  comprise  of 
components  with  different  licenses,  affecting  the  over¬ 
all  system  license.  To  minimize  license  interaction,  a 
configured  system  or  sub-architecture  may  be  sur¬ 
rounded  by  a  license  firewall,  a  layer  of  dynamic  links, 
client-server  connections,  license  shims,  or  other  con¬ 
nectors  that  block  the  propagation  of  reciprocal  obliga¬ 
tions.  The  Affero  General  Public  License  (AGPL)  [2] 
prohibits  using  license  firewalls. 

4.  Understanding  open  software  licenses 

A  particularly  knotty  challenge  is  the  problem  of 
heterogeneous  licenses  in  software  systems.  There  has 


been  an  explosion  in  the  number,  type,  and  variants  of 
software  licenses,  especially  with  open  source  software 
(cf.  [1]).  License  types  include  General  Public  License 
(GPL),  Mozilla  Public  License  (MPL),  Apache  Public 
License,  (APL),  academic  licenses  such  as  Berkeley 
Software  Distribution  (BSD)  and  MIT,  Creative  Com¬ 
mons,  Artistic,  and  Public  Domain  (either  via  explicit 
declaration  or  by  expiration  of  prior  copyright  license). 
Within  each  license  types  are  numerous  variants.  Fur¬ 
thermore,  licenses  can  evolve,  resulting  in  new  license 
versions  over  time.  Finally,  each  license  stipulates 
different  constraints  to  software  components  that  bear 
it.  Discussions  of  many  different  licenses  currently 
used  with  OSS  are  available  [1,7,  17,  19]. 

The  way  components  are  configured  also  affects  the 
license  of  the  overall  system.  Furthermore,  the  com¬ 
ponent  configurations  at  build-time  and  run-time  may 
have  different  license  implications.  For  instance, 
components  may  be  statically  bound  or  interconnected 
at  build-time,  while  other  components  may  only  be 
dynamically  linked  for  execution  at  run-time,  and  thus 
might  not  be  included  as  part  of  a  software  release  or 
distribution.  On  top  of  this,  software  maintenance  such 
as  architectural  refactoring,  alternative  component  in¬ 
terconnections,  and  component  replacement  (via  main¬ 
tenance  patches,  installation  of  new  versions,  or  migra¬ 
tion  to  new  technologies)  can  all  have  effects  on  the 
overall  license  of  the  system. 

4.1.  Software  licenses:  rights  and  obligations 

Copyright,  the  common  basis  for  software  licenses, 
gives  the  original  author  of  a  work  certain  exclusive 
rights,  e.g.  right  to  use,  copy,  modify,  merge,  publish, 
distribute,  sub-license,  and  sell  copies.  These  rights 
may  be  licensed  to  others,  individually  or  in  groups, 
and  either  exclusively  or  non-exclusively.  After  a  pe¬ 
riod  of  years,  the  rights  enter  the  public  domain.  Until 
then  copyright  may  only  be  obtained  through  licensing. 

Licenses  may  impose  obligations  that  must  be  met 
in  order  for  the  licensee  to  realize  the  assigned  rights. 
Commonly  cited  obligations  include  the  obligation  to 
publish  at  no  cost  the  source  code  you  modify  (MPL) 
or  the  reciprocal  obligation  to  publish  all  source  code 
included  at  build-time  or  statically  linked  (GPL).  The 
obligations  may  conflict,  as  when  a  GPL’d  compo¬ 
nent’s  reciprocal  obligation  to  publish  source  code  of 
other  components  is  combined  with  a  proprietary  li¬ 
cense’s  prohibition  of  publishing  source  code.  In  this 
case,  rights  may  not  be  available  for  the  system  as  a 
whole,  not  even  the  right  of  use,  because  the  two  obli¬ 
gations  cannot  simultaneously  be  met. 

The  basic  relationship  between  software  license 
rights  and  obligations  can  be  summarized  as  follows:  if 
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the  specified  obligations  are  met,  then  the  specified 
rights  are  granted.  For  example,  if  you  publish  modi¬ 
fied  source  code  and  sub-licensed  derived  works  under 
MPL,  then  you  get  all  the  MPL  rights  for  the  original 
and  modified  code.  However,  license  details  are  diffi¬ 
cult  to  comprehend  and  track — it  is  easy  to  get  con¬ 
fused  or  make  mistakes.  Licenses  written  by  develop¬ 
ers  are  often  incomplete  and  legally  ambiguous,  while 
those  written  by  lawyers,  are  more  exact  and  complete 
but  can  be  difficult  for  non-lawyers  to  grasp.  The  chal¬ 
lenge  is  multiplied  when  dealing  with  configured  sys¬ 
tems  that  compose  multiple  components  with  hetero¬ 
geneous  licenses,  so  that  the  need  for  legal  interpreta¬ 
tions  begins  to  seem  inevitable  (cf.  [7,  17]). 

4.2.  Expressing  software  licenses 

We  propose  a  scheme  for  expressing  software  li¬ 
censes  that  is  more  formal  and  less  ambiguous  than 
natural  language,  and  that  allows  us  to  identify  con¬ 
flicts  arising  from  the  various  rights  and  obligations 
pertaining  to  two  or  more  component’s  licenses.  We 
considered  relatively  complex  structures  (such  as 
Hohfeld’s  eight  fundamental  jural  relations  [9])  but, 
applying  Occam’s  razor,  selected  a  simpler  structure. 
We  start  with  a  tuple  <actor,  operation,  action,  ob¬ 
ject  for  expressing  a  right  or  obligation.  The  actor  is 
the  “licensee”  for  all  the  licenses  we  have  examined. 
The  operation  is  one  of  the  following:  “may”,  “must”, 
or  “must  not”,  with  “may”  expressing  a  right  and 
“must”  and  “must  not”  expressing  obligations.  A  copy¬ 
right  right  is  only  available  to  entities  who  have  been 
granted  a  sublicense.  Thus,  only  the  listed  rights  are 
available,  and  the  absence  of  a  right  means  that  it  is  not 
available.  The  action  is  a  verb  or  verb  phrase  describ¬ 
ing  what  may,  must,  or  must  not  be  done,  with  the  ob¬ 
ject  completing  the  description.  We  specify  an  object 
separately  from  the  action  to  minimize  the  set  of  ac¬ 
tions.  A  license  may  be  expressed  as  a  set  of  rights, 
with  each  right  associated  with  zero  or  more  obliga¬ 
tions  that  must  be  fulfilled  in  order  to  enjoy  that  right. 
Figure  1  displays  the  tuples  and  associations  for  two  of 
the  rights  and  their  associated  obligations  for  the  aca¬ 
demic  BSD  software  license.  Note  that  the  first  right  is 
granted  without  corresponding  obligations. 

When  designing  an  OA  software  system,  there  are 
heuristics  that  can  be  employed  to  enable  architectural 
design  choices  that  might  otherwise  be  excluded  due  to 
license  conflicts.  First,  it  is  possible  to  employ  a  li¬ 
cense  firewall  that  serves  to  limit  the  scope  of  recipro¬ 
cal  obligations.  Rather  than  simply  interconnecting 
conflicting  components  through  static  linking  of  com¬ 
ponents  at  build-time,  such  components  can  be  logi¬ 
cally  connected  via  dynamic  links,  client-server  proto¬ 


cols,  license  shims  (e.g.,  via  LGPL  connectors),  or  run¬ 
time  plug-ins.  Second,  the  source  code  of  statically 
linked  OSS  components  must  be  made  public.  Third,  it 
is  necessary  to  include  appropriate  notices  and  publish 
required  sources  when  academic  licenses  are  em¬ 
ployed.  However,  even  using  design  heuristics  such  as 
these  (and  there  are  many),  keeping  track  of  license 
rights  and  obligations  across  interconnected  compo¬ 
nents  in  complex  OAs  quickly  become  too  cumber¬ 
some.  Thus,  automated  support  is  needed  to  manage 
the  multi-component,  multi-license  complexity. 

|  cUcensee,  may,  use,  the  binary  form  of  COMPONENTS  | 

|  cUcensee,  may,  redistribute,  derived  or  collective  works  in  binary  form  of  COMPONENTS  | 

cUcensee,  must,  retain,  copyright  notices  in  the  binary  form  of  COMPONENT>  | 

cUcensee,  must,  retain,  the  BSD  conditions  in  the  binary  form  of  COMPONENTS  | 

Figure  1.  A  portion  of  the  BSD  license  tuples 
5.  Automating  software  license  analysis 

If  we  start  from  a  formal  specification  of  a  software 
system’s  architecture,  we  can  associate  software  li¬ 
cense  attributes  with  the  system’s  components,  connec¬ 
tors,  and  sub-system  architectures  and  calculate  the 
copyright  rights  and  obligations  for  the  system’s  con¬ 
figuration.  Accordingly,  we  use  an  architectural  de¬ 
scription  language  specified  in  xADL  [10]  to  describe 
OAs  that  can  be  designed  and  analyzed  with  a  software 
architecture  design  environment  [13],  such  as 
ArchStudio4  [11].  ArchStudio4  currently  has  software 
traceability  tool  support  (cf.  [4])  and  we  have  extended 
it  with  a  Software  Architecture  License  Traceability 
Analysis  module  (see  Fig  2).  This  allows  for  the  speci¬ 
fication  of  licenses  as  a  list  of  attributes  (license  tuples) 
using  a  form-based  user  interface  in  ArchStudio4. 

We  analyze  rights  and  obligations  as  follows: 

Propagation  of  reciprocal  obligations.  We  follow 
the  widely-accepted  interpretation  that  build-time  static 
linkage  propagate  the  reciprocal  obligations,  but  the 
"license  firewalls”  do  not.  Analysis  begins,  therefore, 
by  propagating  these  obligations  along  all  connectors 
that  are  not  license  firewalls. 

Obligation  conflicts.  An  obligation  can  conflict 
with  another  obligation,  or  with  the  set  of  available 
rights,  by  requiring  a  copyright  right  that  has  not  been 
granted.  For  instance,  a  proprietary  license  may  require 
that  a  licensee  must  not  redistribute  source  code,  but 
GPL  states  that  a  licensee  must  redistribute  source 
code.  Thus,  the  conflict  appears  in  the  modality  of  the 
two  otherwise  identical  obligations,  “must  not”  in  a 
proprietary  software  and  “must”  in  GPL. 

Rights  and  obligations  calculations.  The  rights 
available  for  the  entire  system  (use,  copy,  modify,  etc.) 
are  calculated  as  the  intersection  of  the  sets  of  rights 
available  for  each  component  of  the  system.  If  a  con- 
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flict  is  found  involving  the  obligations  and  rights  of 
linked  components,  it  is  possible  for  the  system  archi¬ 
tect  to  consider  an  alternative  linking  scheme,  e.g.  us¬ 
ing  one  or  more  connectors  along  the  paths  between 
the  components  that  act  as  a  license  firewall.  This 
means  that  the  architecture  and  the  environment  to¬ 
gether  can  determine  what  OA  design  best  meets  the 
problem  at  hand  with  available  software  components. 
Components  with  conflicting  licenses  do  not  need  to  be 
arbitrarily  excluded,  but  instead  may  expand  the  range 
of  possible  architectural  alternatives  if  the  architect 
seeks  such  flexibility  and  choice. 


Figure  2:  License  traceability  analysis  tool 

6.  Ongoing  work 

We  are  currently  encoding  major  license  types  such 
as  GPL,  MPL,  CTL  to  examine  the  effectiveness  of  the 
license  tuple  encoding  and  the  calculations  based  upon 
it.  Thus  far,  we  are  finding  that  the  tuple  representa¬ 
tion  is  sufficiently  expressive  for  our  needs.  We  are 
also  currently  evaluating  the  effectiveness  of  our 
automated  license  analysis  on  an  actual  heterogene¬ 
ously  licensed  system.  In  addition,  we  are  exploring 
the  impact  of  patent  and  other  provisions  in  licenses. 
Finally,  we  are  studying  how  the  design  time  and 
build-time  analysis  of  component  configuration  relates 
to  the  eventual  run-time  license  of  a  system. 
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Abstract 

Heterogeneously-licensed  systems  pose  new  challenges 
to  analysts  and  system  architects.  Appropriate  intellectual 
property  rights  must  be  available  for  the  installed  system, 
but  without  unnecessarily  restricting  other  requirements, 
the  system  architecture,  and  the  choice  of  components  both 
initially  and  as  it  evolves.  Such  systems  are  increasingly 
common  and  important  in  e-business,  game  development, 
and  other  domains.  Our  semantic  parameterization  anal¬ 
ysis  of  open-source  licenses  confirms  that  while  most  li¬ 
censes  present  few  roadblocks,  reciprocal  licenses  such  as 
the  GNU  General  Public  License  produce  knotty  constraints 
that  cannot  be  effectively  managed  without  analysis  of  the 
system ’s  license  architecture.  Our  automated  tool  supports 
intellectual  property  requirements  management  and  license 
architecture  evolution.  We  validate  our  approach  on  an  ex¬ 
isting  heterogeneously-licensed  system. 


1.  Introduction 

Until  recently,  the  norm  for  licensed  software  has  been 
that  software  is  used  and  distributed  under  the  terms  of 
a  single  license,  with  all  its  components  homogeneously 
licensed  under  a  single  proprietary  or  open-source  soft¬ 
ware  (OSS)  license.  It  is  increasingly  common  to  see 
heterogeneously-licensed  (HtL)  systems,  whose  compo¬ 
nents  are  not  under  the  same  license  [8,  18,  20].  For  web 
systems  this  has  become  so  common  that  commercial  tools 
for  creating  such  “mashups”  have  been  available  for  several 
years  [9,  11].  Carefully  constrained  design,  possibly  aided 
by  license  exceptions  from  the  copyright  owners,  may  en¬ 
able  the  resulting  system  to  have  a  single  specific  license 
[8].  Otherwise  the  system  as  a  whole  has  no  single  license, 
but  rather  one  or  more  rights  that  are  the  intersection  of  all 
the  component  license’s  rights,  and  the  union  of  their  obli- 
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gations.  An  example  of  a  HtL  system  is  the  Unity  game 
development  tool,  whose  license  agreement  lists  eleven  dis¬ 
tinct  licenses  for  its  components,  in  addition  to  its  overall 
license  terms  granting  the  right  to  use  the  system  [20] . 

The  intellectual  property  (IP)  in  a  system — copyrights, 
patents,  trademarks,  trade  dress,  and  trade  secrets — is  pro¬ 
tected  and  made  available  through  the  licenses  of  the  system 
and  its  components.  IP  requirements  are  expressed  in  terms 
of  these  licenses  and  the  rights  and  obligations  they  entail, 
and  include 

•  the  right  to  use,  distribute,  sublicense,  etc.; 

•  the  component  selection  strategy  (whether  limited  to 
specific  licenses,  or  open  to  “best-of-breed”); 

•  interoperation  of  systems  with  specific  IP  regimes; 

•  the  extent  to  which  the  system  will  be  an  open  archi¬ 
tecture  (OA);  and 

•  how  it  is  distributed  to,  constituted  by,  and  (for  OA 
systems)  evolved  by  users. 

The  IP  requirements  interact  with  the  system’s  design¬ 
time,  distribution-time,  and  run-time  architectures  in  dis¬ 
tinct  ways,  with  the  possibility  of  rights  that  conflict  with 
other  licenses’  obligations,  obligations  that  conflict  across 
licenses,  and  unobtainable  rights.  The  result  can  be  a  sys¬ 
tem  that  can’t  legally  be  sublicensed,  distributed,  or  used,  or 
that  involves  its  developers,  distributors,  or  users  in  legal  li¬ 
abilities.  Of  course,  some  will  ignore  these  legal  issues  (and 
anecdotal  evidence  indicates  that  many  do),  but  companies 
and  governments  cannot  afford  to.  Source  code  scanning 
services  provided  by  third-party  vendors  address  only  one 
after-the-fact  aspect  of  this  problem.  While  heuristics  ex¬ 
ist  for  managing  IP  requirements  and  are  used  in  HtL  sys¬ 
tem  development  practice,  they  impose  costs,  unnecessarily 
limit  the  design  space,  and  can  result  in  a  suboptimal,  un¬ 
satisfactory  system. 

Software  licenses  and  IP  rights  represent  a  new  class  of 
nonfunctional  requirements,  and  constrain  the  development 
of  systems  with  open  architectures. 
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As  part  of  our  ongoing  investigation  of  OSS  and  OA  sys¬ 
tems,  we  performed  a  grounded  theory,  semantic  parameter¬ 
ization  analysis  of  nine  OSS  licenses  [4].  From  this  analysis 
and  related  work  on  OSS  licensing  [7,  17,  19],  we  were  able 
to  produce  a  metamodel  for  software  licenses  and  for  the 
contexts  in  which  they  are  applied,  and  a  calculus  for  license 
rights  and  obligations  in  license  and  context  models.  Using 
them,  we  calculate  rights  and  obligations  for  specific  sys¬ 
tems,  identify  conflicts  and  unsupported  rights,  and  evaluate 
alternative  architectures  and  components  and  guide  choices. 
We  argue  that  these  calculations  are  needed  in  developing 
systems  of  components  whose  licenses  can  conflict,  whose 
design-time,  distribution-time,  and  run-time  architectures 
are  not  identical,  whose  component  licenses  may  change 
through  evolution,  or  for  which  a  “best-of-breed”  compo¬ 
nent  strategy  is  desired.  We  have  validated  the  approach  by 
encoding  the  copyright  rights  and  obligations  for  a  group  of 
OSS  and  proprietary  licenses,  implementing  an  architecture 
tool  to  automate  calculations  on  the  licenses,  and  applying  it 
to  an  OSS-OA  reference  architecture.  These  models  bring 
into  clear  relief  the  knotty  constraints  produced  by  inter¬ 
actions  among  proprietary  licenses  and  reciprocal  licenses 
such  as  the  GNU  General  Public  License  (GPL),  Mozilla 
Public  License  (MPL),  and  IBM’s  Common  Public  License 
(CPL).  We  have  also  discovered  a  novel  second  possible 
mechanism  of  interaction,  through  sources  shared  among 
compiled  components  under  different  licenses. 

The  main  contributions  of  this  work  are  the  concept  of 
a  license  firewall  (Section  3.3);  a  metamodel  for  software 
licenses  (Section  5);  the  concept  of  a  license  architecture 
(Section  5);  an  analysis  process  for  determining  the  rights 
available  for  a  system  and  their  corresponding  obligations 
(Section  6);  an  implementation  of  this  analysis  in  an  archi¬ 
tecture  development  environment  (Section  7);  and  the  con¬ 
cept  of  a  virtual  license  (Section  8). 

The  remainder  of  the  paper  is  organized  as  follows.  Sec¬ 
tion  2  outlines  a  motivating  example  from  our  own  expe¬ 
rience.  Section  3  gives  background.  Related  work  is  in 
Section  4.  We  discuss  our  analysis  and  metamodel  of  OSS 
licenses  in  Section  5,  and  the  system  contexts  and  calcula¬ 
tions  on  them  in  Section  6.  Section  7  presents  our  tool  sup¬ 
port  and  its  application  to  the  reference  model.  We  discuss 
implications  in  Section  8  and  conclude  in  Section  9. 

2.  A  motivating  example 

Heterogeneous  software  licenses  can  limit  architectural 
choices  when  building  and  distributing  multi-component 
systems,  as  illustrated  by  our  recent  experience  prototyp¬ 
ing  a  new  multimedia  content  management  portal  that  in¬ 
cluded  support  for  videoconferencing  and  video  recording 
and  publishing.  Our  prototype  was  based  on  an  Adobe 
Flash  Media  Server  (FMS),  and  we  developed  both  broad¬ 


cast  and  multi-cast  clients  for  video  and  audio  that  shared 
their  data  streams  through  the  FMS.  FMS  is  a  closed  source 
media  server  whose  number  of  concurrent  client  connec¬ 
tions  is  limited  by  a  license  fee.  As  the  FMS  license  did 
not  allow  for  redistribution,  we  could  invite  remote  users 
to  try  out  our  clients  and  media  services,  but  we  could  not 
offer  to  share  the  run-time  environment  that  included  the 
FMS.  We  could  distribute  our  locally-developed  clients  and 
service  source  code.  However,  other  potential  developers 
at  remote  locations  would  then  need  to  download  and  in¬ 
stall  a  licensed  copy  of  the  FMS,  and  then  somehow  re¬ 
build  our  system  using  the  source  code  we  provided  and 
their  local  copy  of  the  FMS.  In  our  view,  this  created  a  bar¬ 
rier  to  sharing  the  emerging  results  from  our  prototyping 
effort.  We  subsequently  undertook  to  replace  the  FMS  with 
Red5,  an  open  source  Flash  media  server,  so  we  could  dis¬ 
tribute  a  run-time  version  of  our  content  management  portal 
to  remote  developers.  Now  these  developers  could  install 
and  use  our  run-time  system,  or  download  the  source  code, 
build,  and  share  their  own  run-time  version.  Our  experience 
shows  how  common  software  R&D  efforts  can  be  hampered 
in  surprising  ways  by  software  components  whose  hetero¬ 
geneous  licenses  limit  distribution  and  sharing  of  work  in 
progress. 

3.  Background 

3.1.  Intellectual  Property  (IP) 

An  individual  can  own  a  tangible  thing,  and  have  prop¬ 
erty  rights  in  it  such  as  the  rights  to  use  it,  improve  it,  sell 
it  or  give  it  away,  or  prevent  others  from  doing  so,  subject 
to  some  statutory  restrictions.  Similarly,  an  individual  can 
own  intellectual  property  (IP)  of  various  types,  and  have 
specific  property  rights  in  the  intangible  intellectual  prop¬ 
erty,  such  as  the  rights  to  copy,  use,  change,  distribute,  or 
prevent  others  from  doing  so,  again  subject  to  some  statu¬ 
tory  restrictions.  In  the  United  States  and  most  other  coun¬ 
tries,  intellectual  property  is  defined  by 

•  copyright  for  a  specific  original  expression  of  an  idea, 

•  patent  for  an  invention, 

•  trademark  for  a  symbol  identifying  the  origin  of  prod¬ 
ucts, 

•  trade  dress  for  distinctive  product  packaging,  and 

•  trade  secret  for  an  idea  kept  confidential. 

Software  licenses  are  primarily  concerned  with  copy¬ 
rights  and  patents,  and  mention  trademarks  only  to  restrict 
a  licensee’s  use  of  them;  licenses  rarely  discuss  trade  dress 
or  trade  secrets  [17].  In  this  paper  we  focus  on  copyright 
aspects  of  licenses. 

Copyright  is  defined  by  Title  17  of  the  U.S.  Code  and 
by  similar  law  in  most  other  countries.  It  grants  exclu- 
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sive  rights  to  the  author  of  an  original  work  in  any  tangi¬ 
ble  means  of  expression,  namely  the  rights  to  reproduce 
the  copyrighted  work;  prepare  derivative  works;  distribute 
copies;  and  (for  certain  kinds  of  work)  perform  or  display  it. 
Because  the  rights  are  exclusive,  the  author  can  prevent  oth¬ 
ers  from  exercising  them,  except  as  allowed  by  “fair  use”. 
The  author  can  also  grant  others  any  or  all  of  the  rights 
or  any  part  of  them;  one  of  the  functions  of  a  software  li¬ 
cense  is  to  grant  such  rights,  and  define  the  conditions  under 
which  they  are  granted. 

Copyright  subsists  in  the  expression  of  the  original  work, 
that  is,  the  rights  begin  from  the  moment  the  work  is  ex¬ 
pressed.  In  the  U.S.  a  copyright  lasts  for  the  author’s  life¬ 
time  plus  70  years,  or  95  years  for  works  for  hire  [21], 

3.2.  Open-Source  Software  (OSS) 

In  contrast  to  traditional  proprietary  licenses,  used  by 
companies  to  retain  control  of  their  software  and  restrict  ac¬ 
cess  and  rights  to  it  outside  of  the  company,  OSS  licenses 
are  designed  to  encourage  sharing  of  software  and  to  grant 
as  many  rights  as  possible.  OSS  licenses  may  be  classified 
as  academic  or  reciprocal.  The  academic  licenses,  includ¬ 
ing  the  Berkeley  Software  Distribution  (BSD)  license,  the 
Massachusetts  Institute  of  Technology  (MIT)  license,  the 
Apache  Software  License  (ASL),  and  the  Artistic  License, 
grant  nearly  all  rights  and  impose  few  obligations.  Anyone 
can  use  the  software,  create  derivative  works  from  it,  or  in¬ 
clude  it  in  proprietary  projects;  typically  the  obligations  are 
to  not  remove  the  copyright  and  license  notices  from  the 
software. 

Reciprocal  licenses  encourage  sharing  of  software  in 
a  different  way,  by  imposing  the  condition  that  the 
reciprocally-licensed  software  not  be  combined  (for  vary¬ 
ing  definitions  of  “combined”)  with  any  software  that  is  not 
then  released  in  turn  under  the  reciprocal  license.  The  goal 
is  to  ensure  that  as  open  software  is  improved,  by  whomever 
and  for  whatever  purpose,  it  remains  open.  The  means  is 
by  preventing  improvements  from  vanishing  behind  closed, 
proprietary  licenses.  Examples  of  reciprocal  licenses  are 
GPL,  MPL,  and  CPL. 

Licenses  of  both  types  typically  disclaim  liability,  assert 
that  no  warranty  is  implied,  and  obligate  licensees  to  not  use 
the  licensor’s  name  or  trademark.  Newer  licenses  tend  to 
discuss  patent  issues,  either  giving  a  limited  patent  license 
along  with  the  other  rights,  or  stating  that  patent  rights  are 
not  included. 

Several  newer  licenses  add  interesting  degrees  of  flex¬ 
ibility.  Most  licenses  grant  the  right  to  sublicense  under 
the  same  license,  or  in  some  cases  under  any  version  of 
the  same  license.  IBM’s  CPL  grants  the  right  to  subli¬ 
cense  under  any  license  that  meets  certain  conditions;  CPL 
itself  meets  them,  of  course,  but  several  other  licenses  do 


as  well.  Finally,  the  Mozilla  Disjunctive  Tri-License  li¬ 
censes  the  core  Mozilla  components  under  any  one  of  three 
licenses  (MPL,  GPL,  or  the  GNU  Lesser  General  Public  Li¬ 
cense  LGPL);  OSS  developers  can  choose  the  one  that  best 
suits  their  needs  for  a  particular  project  and  component. 

The  Open  Source  Initiative  (OSI)  maintains  standards 
for  OSS  licenses,  reviews  OSS  licenses  under  those  stan¬ 
dards,  and  gives  its  approval  to  those  that  meet  them  [16]. 
OSI  publishes  a  standard  repository  of  approximately  70  ap¬ 
proved  OSS  licenses. 

It  has  been  common  for  OSS  projects  to  require  that 
developers  contribute  their  work  under  conditions  that  en¬ 
sure  the  project  can  license  its  products  under  a  specific 
OSS  license.  For  example,  the  Apache  Contributor  Li¬ 
cense  Agreement  grants  enough  of  each  author’s  rights  to 
the  Apache  Software  Foundation  for  the  foundation  to  li¬ 
cense  the  resulting  systems  under  the  Apache  Software  Li¬ 
cense.  This  sort  of  license  configuration,  in  which  the  rights 
to  a  system’s  components  are  homogenously  granted  and 
the  system  has  a  well-defined  OSS  license,  was  the  norm 
and  continues  to  this  day. 

3.3.  Open  Architecture  (OA) 

Open  architecture  (OA)  software  is  a  customization  tech¬ 
nique  introduced  by  Oreizy  [15]  that  enables  third  parties 
to  modify  a  software  system  through  its  exposed  archi¬ 
tecture,  evolving  the  system  by  replacing  its  components. 
Almost  a  decade  later,  we  see  more  and  more  software¬ 
intensive  systems  developed  using  an  OA  strategy  not  only 
with  open  source  software  (OSS)  components  but  also  pro¬ 
prietary  components  with  open  APIs  (e.g.  [20]).  Develop¬ 
ing  systems  using  the  OA  technique  can  lower  development 
costs  [18].  Composing  a  system  with  HtL  components, 
however,  increases  the  likelihood  of  liabilities  stemming 
from  incompatible  licenses.  Thus,  in  this  paper,  we  define 
an  OA  system  as  a  software  system  consisting  of  compo¬ 
nents  that  are  either  open  source  or  proprietary  with  open 
API,  whose  overall  system  rights  at  a  minimum  allow  its  use 
and  redistribution. 

OA  may  simply  seem  to  mean  software  system  architec¬ 
tures  incorporating  OSS  components  and  open  application 
program  interfaces  (APIs).  But  not  all  such  architectures 
will  produce  an  OA,  since  the  available  license  rights  of  an 
OA  depend  on;  (a)  how  and  why  OSS  and  open  APIs  are 
located  within  the  system  architecture,  (b)  how  OSS  and 
open  APIs  are  implemented,  embedded,  or  interconnected, 
and  (c)  the  degree  to  which  the  licenses  of  different  OSS 
components  encumber  all  or  part  of  a  software  system’s  ar¬ 
chitecture  into  which  they  are  integrated  [1,  18]. 

The  following  kinds  of  software  elements  appearing  in 
common  software  architectures  can  affect  whether  the  re¬ 
sulting  systems  are  open  or  closed  [2], 
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Software  source  code  components — These  can  be  ei¬ 
ther  (a)  standalone  programs,  (b)  libraries,  frameworks,  or 
middleware,  (c)  inter-application  script  code  such  as  C  shell 
scripts,  or  (d)  intra-application  script  code,  as  for  creating 
Rich  Internet  Applications  using  domain-specific  languages 
such  as  XUL  for  the  Firefox  Web  browser  [6]  or  “mashups” 
[14],  Each  may  have  its  own  license. 

Executable  components — These  components  are  in  bi¬ 
nary  form,  and  the  source  code  may  not  be  open  for  ac¬ 
cess,  review,  modification,  or  possible  redistribution  [17]. 
If  proprietary,  they  often  cannot  be  redistributed,  and  so  are 
present  in  the  design-  and  run-time  architectures  but  not  at 
distribution- time. 

Software  services — An  appropriate  software  service 
can  replace  a  source  code  or  executable  component. 

Application  program  interfaces/APIs — Availability  of 
externally  visible  and  accessible  APIs  is  the  minimum  re¬ 
quirement  to  form  an  “open  system”  [13].  APIs  are  not  and 
cannot  be  licensed,  and  can  limit  the  propagation  of  license 
obligations. 

Software  connectors — Software  whose  intended  pur¬ 
pose  is  to  provide  a  standard  or  reusable  way  of  commu¬ 
nication  through  common  interfaces,  e.g.  High  Level  Ar¬ 
chitecture  [12],  CORBA,  MS  .NET,  Enterprise  Java  Beans, 
and  GNU  Lesser  General  Public  License  (LGPL)  libraries. 
Connectors  can  also  limit  the  propagation  of  license  obliga¬ 
tions. 

Methods  of  connection — These  include  linking  as  part 
of  a  configured  subsystem,  dynamic  linking,  and  client- 
server  connections.  Methods  of  connection  affect  license 
obligation  propagation,  with  different  methods  affecting 
different  licenses. 

Configured  system  or  subsystem  architectures — 

These  are  software  systems  whose  internal  architecture  may 
comprise  components  with  different  licenses,  affecting  the 
overall  system  license.  To  minimize  license  interaction,  a 
configured  system  or  sub-architecture  may  be  surrounded 
by  what  we  term  a  license  firewall,  namely  a  layer  of  dy¬ 
namic  links,  client-server  connections,  license  shims,  or 
other  connectors  that  block  the  propagation  of  reciprocal 
obligations. 

Figure  1  provides  an  overall  view  of  a  reference  ar¬ 
chitecture  that  includes  all  the  software  elements  above. 
This  reference  architecture  has  been  instantiated  in  a 
number  of  configured  systems  that  combine  OSS  and 
closed  source  components.  One  such  system  handles 
time  sheets  and  payroll  at  the  university;  another  im¬ 
plements  the  web  portal  for  a  university  research  lab 
(http://proxy.arts.uci.edu/gamelab/).  The  configured  sys¬ 
tems  consist  of  software  components  such  as  a  Mozilla  Web 
browser,  Gnome  Evolution  email  client,  and  WordPerfect 
word  processor,  all  running  on  a  Linux  operating  system  ac¬ 
cessing  file,  print,  and  other  remote  networked  servers  such 
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as  an  Apache  Web  server.  The  components  are  intercon¬ 
nected  through  a  set  of  software  connectors  that  bridge  the 
interfaces  of  components  and  combine  the  provided  func¬ 
tionality  into  the  system’s  services. 

4.  Related  work 

There  has  been  little  explicit  guidance  on  how  best  to  de¬ 
velop,  deploy,  and  sustain  complex  software  systems  when 
different  OA  and  OSS  objectives  are  at  hand.  Ven  [22]  and 
German  [8]  are  recent  exceptions. 

Ven  discusses  the  challenges  faced  by  independent  soft¬ 
ware  vendors  who  develop  software  using  OSS  and  propri¬ 
etary  components,  focusing  on  the  evolution  and  mainte¬ 
nance  of  modified  OSS  components  [22], 

German  models  a  license  as  a  set  of  grants,  each  of  which 
has  a  set  of  conjoined  conditions  necessary  for  the  grant  to 
be  given  [8].  Interaction  between  licenses  is  analyzed  by 
examining  pairs  of  licenses  in  the  context  of  five  types  of 
component  connection.  He  also  identify  twelve  patterns  for 
avoiding  license  mismatches,  found  in  a  large  group  of  OSS 
projects,  and  characterize  the  patterns  using  their  model. 
Our  license  model  extends  German’s  to  address  semantic 
connections  between  obligations  and  rights. 

Legal  scholars  have  examined  OSS  licenses  and  how 
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they  interact  in  the  legal  domain,  but  not  how  licenses  apply 
to  specific  HtL  systems  and  contexts  [7,  19].  For  example, 
Rosen  surveys  eight  existing  OSS  licenses  and  creates  two 
more  of  his  own,  the  Open  Source  License  and  the  Aca¬ 
demic  Free  License,  written  to  professional  legal  standards 
[17],  He  examines  license  interactions  primarily  in  terms 
of  the  categories  of  reciprocal  and  non-reciprocal  licenses, 
rather  than  in  terms  of  specific  licenses. 

Breaux  et  al.  have  analyzed  regulatory  rules  in  another 
domain,  that  of  privacy  and  security  [3,  4],  We  adapt  their 
approach  in  our  analysis  of  OSS  licenses. 

Our  previous  work  examines  how  best  to  align  acquisi¬ 
tion,  system  requirements,  architectures,  and  OSS  elements 
across  different  software  license  regimes  to  achieve  the  goal 
of  combining  OSS  and  OA  [18]. 

5.  Analyzing  software  licenses 

A  particularly  knotty  challenge  is  the  problem  of  hetero¬ 
geneous  licenses  in  software  systems.  In  order  to  illuminate 
the  specifics  of  this  challenge  and  provide  a  basis  for  ad¬ 
dressing  it,  we  analyzed  a  representative  group  of  common 
OSS  licenses  and  (for  contrast)  a  proprietary  license,  using 
an  approach  based  on  Breaux’s  semantic  parameterization 

[4]. 

We  analyzed  these  licenses: 

1.  Apache  2.0 

2.  Berkeley  Software  Distribution  (BSD) 

3.  Common  Public  License  (CPL) 

4.  Eclipse  Public  License  1 .0 

5.  GNU  General  Public  License  2  (GPL) 

6.  GNU  Lesser  General  Public  License  2.1  (LGPL) 

7.  MIT 

8.  Mozilla  Public  License  1.1  (MPL) 

9.  Open  Software  License  3.0  (OSL) 

10.  Corel  Transactional  License  (CTL) 

We  obtained  the  text  of  the  nine  OSS  license  from  the 
Open  Source  Initiative  web  site  [16],  and  the  text  of  the 
proprietary  CTL  license  from  Corel’s  web  site  [5]. 

The  stages  of  the  analysis  were: 

1.  First  we  disambiguated  forward  and  backward  ref¬ 
erences,  identified  synonyms,  and  distinguished  pol¬ 
ysemes  that  expressed  different  meanings  with  identi¬ 
cal  wording.  We  identified  terms  of  art  from  copyright 
law,  such  as  “Derived  Work”,  and  specialized  terms 
defined  for  a  particular  license,  such  as  “work  based 
on  the  Program”  for  GPL  and  “Electronic  Distribu¬ 
tion  Mechanism”  for  MPL.  From  this  we  constructed 
(automatically)  a  concordance  to  aid  us  in  the  remain¬ 
der  of  the  analysis.  The  concordance  indexed  the  in¬ 
stances  of  each  distinguished  word  term,  excluding  mi- 


0.  |S2.0pisi|  This  License  applies  to  any  program  or  other  work  which 
contains  a  notice  placed  by  the  copyright  holder  saying  it  may  be 
distributed  under  the  terms  of  this  General  Public  License. 

|S2.0pis2|  The  "Program",  below,  refers  to  any  such  program  or  work, 
and  a  "work  based  on  the  Program"  means  either  the  Program  or 
any  derivative  work  under  copyright  law:  that  is  to  say,  a  work 
containing  the  Program  or  a  portion  of  it,  either  verbatim  or  with 
modifications  and/or  translated  into  another  language. 

|S2.0pls3|  ('Hereinafter,  translation  is  included  without  limitation  in  the 
term  "modification".  1  |S2.0pis4|  Each  licensee  is  addressed  as  "you". 

Figure  2.  GPL  2  concordance,  sect.  2.0  par.  1 
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nor  words  such  as  articles,  conjunctions,  and  preposi¬ 
tions  whose  use  in  a  particular  license  carried  no  spe¬ 
cialized  meaning,  and  tagged  each  sentence  with  its 
section,  paragraph,  and  sentence  sequence  numbers. 
Figure  2  shows  a  portion  of  the  concordance  for  GPL. 

2.  Next  we  identified  the  parts  of  each  license  that  had 
no  legal  force,  such  as  GPL  2’s  “Preamble”  section, 
or  that  dealt  with  any  rights  or  obligations  other  than 
those  for  copyright,  such  as  patents,  trademarks,  im¬ 
plied  warranty,  or  liability,  iterating  with  the  concor¬ 
dance  to  confirm  the  identifications.  The  remainder  of 
our  analysis  focused  on  copyright. 

3.  Using  the  concordances  across  the  licenses,  and  guided 
by  legal  work  on  OSS  licenses  [7,  17,  19],  we  iden¬ 
tified  words  and  phrases  with  the  same  intensional 
meaning,  and  textual  structures  parallel  among  the  li¬ 
censes.  From  these  we  iterated  to  identify  natural  lan¬ 
guage  patterns  each  of  which  could  be  used  as  a  re¬ 
stricted  natural  language  statement  (RNLS)  to  express 
the  licenses. 

Our  metamodel,  derived  from  the  patterns  we  identi¬ 
fied,  is  shown  in  Figure  3.  A  license  consists  of  one  or 
more  rights,  each  of  which  entails  zero  or  more  obligations. 
Rights  and  obligations  have  the  same  structure,  a  tuple  com¬ 
prising  an  actor  (the  licensor  or  licensee ),  a  modality,  an  ac¬ 
tion,  an  object  of  the  action,  and  possibly  a  license  referred 
to  by  the  action. 
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We  found  a  wide  variety  of  license  actions,  some  of 
which  are  defined  in  copyright  law  or  derived  from  it  and 
are  distinguished  as  copyright  actions.  The  possible  modal¬ 
ities,  objects,  and  licenses  are  shown  in  Figure  4. 

The  RNLS  textual  form  of  an  example  abstract  right, 
(one  not  bound  to  a  specific  object)  extracted  from  the  BSD 
license  is 

Licensee  •  may  •  distribute  <Any  Source>  under 
<This  License  > 

where  “distribute  under”  is  a  copyright  action  and  the  ab¬ 
stract  object  <Any  Source>  quantifies  the  right  over  all 
sources  licensed  under  the  license  containing  the  right  (here, 
BSD);  an  example  concrete  obligation  is 

Licensee  •  must  •  retain  the  [BSD]  copyright  no¬ 
tice  in  [f  ile  .  c] 

where  “retain  the  copyright  notice”  is  an  action  that  is  not 
a  copyright  action,  BSD  is  the  concrete  license  the  action 
references,  and  f  ile  .  c  is  the  concrete  object  the  action 
references.  The  RNLS  actions  are  defined  with  tokens 
identifying  where  the  tuple’s  object  and  (if  present)  license 
are  inserted,  for  example  in  the  GPL  action  “sublicense  % 
under  which  becomes  “sublicense  OBJECT  under  LI¬ 
CENSE”.  Figure  5  is  an  informal  illustration  of  how  actions 
may  contain  concrete  objects  and  licenses,  references  to  ob¬ 
jects  or  licenses  bound  elsewhere,  or  quantifiers  using  the 
information  in  the  license  architecture  abstraction  described 
below  to  produce  sets  of  rights  or  obligations. 

We  used  the  metamodel  to  express  the  software  li¬ 
censes  and  their  rights,  obligations,  and  lower  level  com¬ 
ponents  as  Java  objects.  The  constants  for  the  two  actors, 
the  four  modalities,  and  the  two  license  quantifiers  were 
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Figure  6.  Partial  order  of  copyright  actions; 
actions  defined  in  the  Copyright  Act  in  bold 


implemented  as  singleton  objects  of  classes  that  imple¬ 
mented  their  semantics.  Copyright  actions  became  defined 
constants  of  the  Action  class,  while  the  remaining  non¬ 
copyright  actions  were  unified  if  their  intensional  meanings 
were  identical.  From  this  basis  we  constructed  singleton 
objects  for  each  license,  reusing  the  same  object  for  each 
instance  of  its  concept  in  the  licenses. 

From  our  analysis  we  confirmed  that  the  copyright  ac¬ 
tions  form  a  partial  order,  in  which  a  higher  copyright  im¬ 
plies  the  rights  it  is  connected  to  below  it. 

Figure  6  shows  a  portion  of  the  copyright  partial  order, 
using  brief  phrases  to  identify  each  defined  action.  The 
relation  defining  the  order  is  “implied  by”.  For  example, 
“copy”  is  implied  by  “sublicense  unmodified”,  since  it  ac¬ 
complishes  nothing  to  sublicense  copies  without  making 
copies,  so  if  we  are  obligated  to  sublicense  an  unmodified 
component  but  fail  to  have  the  right  to  copy  it,  we  cannot 
meet  our  obligation  and  do  not  have  whatever  rights  de¬ 
mand  it.  The  copyright  actions  are  the  ones  specifically 
mentioned  in  the  Copyright  Act  [21];  we  incorporated  all 
actions  appearing  in  the  licenses  we  analyzed  into  the  full 
ordering. 

This  model  of  licenses  gives  a  basis  for  reasoning  about 
licenses,  applying  them  to  actual  systems,  and  calculating 
the  results.  The  additional  information  we  need  about  the 
system  is  defined  by  the  list  of  quantifiers  that  can  appear 
as  objects  in  the  rights  and  obligations.  The  information 
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Figure  7.  The  license  architecture  metamodel 


needed  is  the  license  architecture  (LA),  an  abstraction  of 
the  system  architecture: 

1 .  the  set  of  components  of  the  system; 

2.  the  relation  mapping  each  component  to  its  license; 

3.  the  relation  mapping  each  component  to  its  set  of 
sources;  and 

4.  the  relation  from  each  component  to  the  set  of  com¬ 
ponents  in  the  same  license  scope,  for  each  license  for 
which  “scope”  is  defined  (e.g.  GPL),  and  from  each 
source  to  the  set  of  sources  of  components  in  the  scope 
of  its  component  (Figure  7). 

With  this  information  and  definitions  of  the  licenses  in¬ 
volved,  we  calculate  rights  and  obligations  for  individual 
components  or  for  the  entire  system,  and  guide  HtL  system 
design. 

We  note  that  the  obligation  quantifiers  we  identified  in 
OSS  licenses  include  ones  that  can  set  up  conflicts  through 
the  license  scopes,  as  is  well  known  for  GPL  and  other  re¬ 
ciprocal  licenses.  However,  we  also  identified  an  obligation 
quantifier  over  all  sources  of  a  component,  and  note  that 
it  raises  the  possibility  of  a  conflict  arising  through  com¬ 
ponents  that  share  a  source.  We  believe  this  conflict  path  is 
novel,  and  are  investigating  in  what  contexts,  if  any,  it  could 
occur. 

6.  Analyzing  license  architectures 

In  order  to  make  calculations  about  the  rights  and  obli¬ 
gations  for  a  specific  system,  we  iterate  over  its  compo¬ 
nents,  instantiating  each  component’s  license  with  the  com¬ 
ponent’s  information.  From  the  resulting  concrete  rights 
and  obligations,  we  can  determine  the  set  of  rights  available 
for  the  system  as  a  whole,  and  the  set  of  concrete  obliga¬ 
tions  that  must  be  met  in  order  to  get  those  rights. 

The  instantiation  proceeds  conceptually  as  follows. 

Each  of  the  abstract  rights  in  every  license  has  as  its  ob¬ 
ject  either  “Any  Under  This  License”,  “Any  Source  Under 
This  License”,  or  “Any  Component  Under  This  License”. 


An  abstract  right  R  in  license  L  is  made  into  one  or  more 
concrete  rights  by  replacing  “Any  Component”  with  each 
component  licensed  under  L  in  succession,  “Any  Source” 
similarly  with  sources,  and  “Any”  with  either.  If  the  abstract 
right  R's  license  is  “Object’s  License”,  then  in  each  concrete 
right  r  the  license  is  replaced  by  r’s  object’s  license. 

Each  of  R's  obligations  0  is  made  into  one  or  more  con¬ 
crete  obligations  o  for  each  r.  If  O' s  object  is  “Right’s  Ob¬ 
ject”,  then  there  will  be  a  single  o,  and  r’s  object  is  used 
as  its  object;  if  O’s  object  is  “All  Sources  Of  Right’s  Ob¬ 
ject”,  then  there  will  be  an  o  for  each  source  s  of  r’s  object 
(which  must  be  a  component),  and  that  o' s  object  will  be 
,y;  if  0’s  object  is  “1/  Scope  Components”  for  some  license 
L’ ,  then  there  will  be  an  o  for  each  component  c  in  r’s  ob¬ 
ject’s  scope,  under  the  definition  of  “scope”  in  L',  and  that 
o’s  object  will  be  c;  and  if  0’s  object  is  “L1  Scope  Sources” 
then  analogously  for  each  such  component’s  sources. 

However,  we  do  not  yet  know  how  to  fulfill  these  con¬ 
crete  obligations.  We  generate  the  correlative  right  from  the 
correlate  of  the  obligation’s  modality  (“may”  for  “must”, 
“need  not”  for  “must  not”)  and  the  remaining  parts  of  the 
obligation.  If  the  correlative  right  is  a  copyright  right,  we 
must  use  its  object’s  license  to  fulfill  it:  we  seek  the  license 
of  this  right’s  object,  find  an  abstract  right  that  generalizes 
this  right,  and  iterate  the  process  for  this  abstract  right  and 
the  parts  of  the  correlative  right.  If  there  is  no  such  right  in 
the  license,  we  iterate  it  again  for  the  right’s  successive  con¬ 
taining  rights  in  the  partial  order  of  copyright  rights,  hoping 
to  get  all  the  rights  that  include  it.  If  not,  we  save  the  cor¬ 
relative  right  as  an  unfulfilled  correlative  right. 

If  the  correlative  right  is  not  a  copyright  right,  we  do  not 
have  to  obtain  it  through  a  license.  However,  we  must  still 
check  whether  it  conflicts  with  an  obligation.  After  all  the 
obligations  have  been  determined,  we  compare  it  against 
them,  looking  for  the  opposite  obligation,  the  obligation 
that  matches  the  right’s  actor,  action,  object,  and  modal¬ 
ity,  but  has  the  opposite  modality  (“must  not”  for  “may”, 
“must”  for  “need  not”).  If  we  find  such  an  obligation,  then 
there  is  a  right-obligation  conflict. 

Finally,  we  go  through  the  concrete  obligations  looking 
for  pairs  of  obligations  identical  except  for  their  modali¬ 
ties.  A  pair  of  such  obligations  indicates  an  obi  i  gat  ion - 
obligation  conflict. 

The  presence  of  any  unfulfilled  correlative  rights,  right- 
obligation  conflicts,  or  obligation-obligation  conflicts  indi¬ 
cates  that  the  full  set  of  license  rights  can’t  be  achieved  for 
all  the  components  in  the  system.  However,  we  may  not 
need  the  full  set  of  rights.  More  commonly  we  need  a  sub¬ 
set  of  the  copyright  rights,  for  example  the  rights  to  use  and 
distribute  the  system.  This  is  equivalent  to  having  that  set 
of  rights  for  each  component  of  the  system,  determined  by 
examining  each  component’s  rights  for  the  desired  rights. 

If  rights  are  those  desired,  then  the  collected  concrete 
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Figure  8.  The  license  architecture  analysis  tool  identifying  unavailable  rights 


obligations  for  then  forms  the  basis  for  automated  testing 
that  IP  obligations  have  been  met  [18]. 

The  process  outlined  above  is  not  one  that  developers 
would  be  keen  to  follow  manually.  In  the  next  section  we 
discuss  an  approach  for  automating  it,  both  to  examine  its 
potential  usefulness  as  an  HtL  system  development  tool  and 
to  validate  the  analysis  process. 

7.  Automating  the  analysis 

We  implemented  the  analysis  tool  within  the  traceability 
view  of  the  ArchStudio  software  architecture  environment 
[10].  We  annotated  the  xADL  software  architecture  model 
with  component  licenses  and  sources  and  used  subarchitec¬ 
tures  to  model  scopes.  This  approach  provides: 

•  The  ability  to  model  software  systems  and  specify  the 
corresponding  licenses  at  different  levels  of  granular¬ 
ity.  We  provide  the  option  of  specifying  licenses  at 
a  fine-grained  level,  for  example  licenses  assigned  to 
components  at  the  level  of  a  single  Web  service,  such 
as  the  Google  Desktop  Query  API,  or  at  a  coarse¬ 
grained  level,  for  example  one  license  assigned  to  a  set 
of  services  provided  by  Google  Desktop  APIs  http : 
/ / code . google . com/ apis/desktop/. 


•  The  ability  to  model  software  systems  at  different  ar¬ 
chitecture  levels  and  to  analyze  license  interactions 
across  the  different  architecture  levels.  For  instance, 
if  a  sub-subsystem  X  contains  heterogeneous  licenses 
and  is  itself  part  of  a  bigger  system  Y  with  heteroge¬ 
neous  licenses,  our  approach  is  able  to  analyze  license 
interactions  between  sub-subsystem  X  and  System  Y. 
We  expect  to  analyze  license  interactions  across  multi¬ 
ple  architecture  levels. 

•  The  modeling  approach  maps  well  to  the  way  real  soft¬ 
ware  systems  are  configured. 

•  Automated  license  analysis  is  informed  by  the  addi¬ 
tional  knowledge  of  the  system  configuration.  This  is 
one  of  our  contributions  beyond  current  techniques  and 
approaches.  Simply  modifying  the  system  configura¬ 
tion  can  result  in  different  sets  of  available  rights  or 
required  obligations.  Thus,  the  same  set  of  compo¬ 
nents  may  be  analyzed  with  or  without  specific  license 
firewalls  inserted  among  them. 

Figure  8  shows  an  analysis  of  a  design  that  specializes 
the  reference  architecture  in  Figure  1 . 

Scalability  is  always  an  issue  for  any  approach.  We  con¬ 
clude  that  our  initial  algorithm  is  quadratic  in  the  number  of 
components  with  licenses,  which  for  architectures  of  up  to 
several  hundred  components  is  manageable.  The  approach 
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requires  modeling  the  system  architecture,  in  common  with 
many  other  research  approaches,  and  annotating  it  to  pro¬ 
duce  the  license  architecture,  which  we  feel  is  a  worthwhile 
tradeoff  for  developers  following  a  best-of-breed  strategy  or 
who  need  to  manage  reciprocal  and  proprietary  components 
or  design-,  distribution-,  and  run-time  architectures  that  dif¬ 
fer  in  significant  ways. 

The  integration  of  the  analysis  with  architecture  design 
and  evaluation  supports  easy  management  of  licenses  across 
the  software  development  lifecycle  and  across  product  vari¬ 
ations.  For  instance,  as  the  software  evolves,  analysts  may 
consider  replacing  a  proprietary  word  processing  compo¬ 
nent  with  an  OSS  component.  By  simply  modifying  the 
architecture  model  and  running  the  automated  license  anal¬ 
ysis,  the  analyst  learns  the  new  set  of  rights  and  obligations. 
Similarly,  an  analyst  can  create  product  variations  to  suit 
a  particular  deployment  platform  or  customer  IP  require¬ 
ments.  These  product  variations  can  be  stored  with  Arch- 
Studio  and  retrieved  or  analyzed  at  any  later  time. 

8.  Discussion 

Our  efforts  in  this  study  are  motivated  in  part  by  a  desire 
to  understand  how  best  to  accommodate  the  development 
of  complex  software  systems  whose  components  may  be 
subject  to  different  IP  licenses.  These  licenses  stipulate  the 
rights  and  obligations  that  must  be  ensured.  However,  sys¬ 
tem  composition  can  incorporate  components  with  different 
licenses  at  architectural  design  time,  at  distribution  time,  or 
at  installed  release  run  time.  Thus,  we  must  consider  what 
overall  license  schemes  we  can  accommodate,  as  well  as 
identify  the  consequences  (freedoms  and  constraints)  each 
scheme  can  realize. 

There  are  at  least  two  kinds  of  software  license/IP 
schemes  that  impose  requirements  on  how  software  sys¬ 
tems  will  be  developed:  (a)  a  single  license  for  the  complete 
software  system,  and  (b)  a  heterogeneous  license  scheme  of 
rights  and  obligations  for  the  complete  system  incorporat¬ 
ing  components  with  different  licenses.  We  consider  each 
in  turn. 

A  single  license  scheme — There  is  often  a  desire  to  spec¬ 
ify  a  single  license  at  architecture  design  time  in  order  to  in¬ 
sure  a  composed  software  system  with  single  license  com¬ 
patible  scheme  at  distribution  time,  and  also  at  run  time. 
Software  licenses  like  GPL  encourage  this  as  part  of  their 
overall  IP  strategy  for  insuring  software  freedom.  Similarly, 
there  is  desire  to  determine  whether  a  single  known  license 
can  cover  a  designed  or  released  system  [8],  However,  a  sin¬ 
gle  license  regime  cannot  in  general  be  guaranteed  to  occur 
by  chance;  instead  it  is  most  effectively  determined  by  de¬ 
sign.  In  either  case,  it  must  be  specified  as  a  nonfunctional 
requirement  for  software  development.  But  satisfying  such 
a  requirement  limits  the  choice  of  software  components  that 


can  be  included  in  the  system  design  and  the  system  compo¬ 
sition  at  distribution-  and  run-time  to  those  compatible  (or 
subsumed)  with  the  required  overall  system  license.  Conse¬ 
quently,  our  goal  in  this  case  is  to  insure  a  simple,  homoge¬ 
neous  scheme  relying  on  known  licenses  to  determine  the 
propagation  and  enforcement  of  their  constraints. 

A  heterogeneous  license  scheme — In  contrast  to  a  sin¬ 
gle  license  scheme,  a  heterogeneous  license  scheme  allows 
a  software  system  to  incorporate  components  with  differ¬ 
ent  IP  licenses.  Such  a  scheme  gives  more  degrees  of  free¬ 
dom  than  a  single  license  scheme.  For  example,  it  allows 
for  best-of-breed  component  selection,  considering  compo¬ 
nents  with  a  range  of  licenses  rather  than  only  those  with  a 
specific  license.  It  also  allows  for  specification  and  design 
of  software  systems  conforming  to  a  reference  architecture 
[2],  This  enables  a  higher  degree  of  software  reuse  through 
inclusion  of  reusable  software  components  that  have  a  sub¬ 
stantial  prior  investment  in  their  development  and  use.  Sim¬ 
ilarly,  when  relying  on  a  reference  architecture,  design-time 
component  choices  need  not  be  encumbered  by  license  con¬ 
straints,  since  the  resulting  system  license  rights  and  obliga¬ 
tions  need  only  be  determined  at  distribution-time  and  run¬ 
time.  Furthermore,  the  distribution-  and  run-time  system 
compositions  are  not  limited  to  a  single  license;  instead  they 
are  constrained  only  by  the  license  rights  and  obligations 
that  ensue  for  the  entire  system. 

In  a  heterogeneous  license  scheme,  the  overall  system 
rights  and  obligations  can  form  a  virtual  license — a  license 
whose  rights  and  obligations  can  be  determined,  tested,  and 
satisfied  at  any  time,  without  being  a  previously  approved 
license  type,  e.g.  via  the  OSI  license  approval  scheme  [16]. 

This  enables  prototyping  both  software  system  composi¬ 
tions  and  new  software  license  types,  and  determining  their 
effect  when  later  mixed  with  existing  software  components 
or  licenses.  However,  determining  the  scope  of  rights  and 
obligations  in  an  overall  composed  system  will  be  challeng¬ 
ing  without  an  automated  tool  such  as  the  one  we  demon¬ 
strated. 

Overall,  the  key  observation  is  that  there  is  a  choice  of 
ways  to  proceed  in  terms  of  guidance  both  for  those  who 
seek  a  single  license  regime  for  all  components  and  system 
compositions,  as  in  GPL-based  software,  and  for  those  who 
seek  to  work  with  multiple  software  component  licenses  in 
order  to  develop  the  best  possible  system  designs  they  can 
realize. 

Finally,  it  now  appears  possible  to  design  a  pure  software 
IP  requirements  analysis  tool  whose  purpose  is  to  reconcile 
the  rights  and  obligations  of  different  licenses,  whether  new 
or  established.  Such  a  tool  will  not  depend  on  specific  soft¬ 
ware  architectures  or  distributions  for  analysis.  It  may  be  of 
value  especially  to  legal  scholars  or  IP  lawyers  who  want 
to  design  or  analyze  alternative  IP  rights  and  obligations 
schemes,  as  well  as  to  software  engineers  who  want  to  de- 
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velop  systems  with  assurable  IP  rights  and  obligations.  That 
tool  is  beyond  the  scope  of  our  effort  here.  But  it  is  note¬ 
worthy  that  such  a  tool  can  emerge  from  careful  analysis  of 
the  requirements  for  open  architecture  software  systems  of 
HtL  components. 

9.  Conclusion 

Software  licenses  and  IP  rights  represent  a  new  class  of 
nonfunctional  requirements  that  increasingly  constrain  the 
development  of  heterogeneously-licensed  systems.  There 
has  been  no  model  to  support  analysis  and  management  of 
these  requirements  in  the  context  of  specific  systems,  and 
the  heuristics  used  in  practice  to  deal  with  them  unnecessar¬ 
ily  limit  the  design  and  implementation  choices.  It  has  not 
been  possible  to  follow  a  best-of-breed  strategy  in  select¬ 
ing  components  without  unduly  constraining  architectural 
decisions. 

In  this  paper  we  have  presented  a  metamodel  for  soft¬ 
ware  licenses  through  which  they  can  be  made  the  bases 
of  IP  rights  calculations  on  system  architectures.  We  de¬ 
fined  the  concepts  of  a  license  firewall,  license  architecture, 
and  virtual  license,  providing  a  basis  for  analyzing  and  un¬ 
derstanding  the  issues  involved  in  HtL  system  IP  rights. 
We  outlined  an  algorithm  for  calculating  concrete  rights 
and  obligations  for  system  architectures  that  identifies  con¬ 
flicts  and  needed  rights,  and  validated  the  metamodel  and 
algorithm  by  formalizing  licenses,  incorporating  model,  li¬ 
censes,  and  algorithm  into  the  ArchStudio  environment,  and 
calculating  IP  rights  and  obligations  for  an  existing  refer¬ 
ence  architecture  and  an  instantiation. 

Future  work  includes  abstracting  our  approach  to  work 
with  licenses  in  the  absence  of  specific  systems,  extending 
it  to  patent  aspects  of  OSS  licenses,  and  applying  it  to  the 
challenges  of  software  acquisition. 
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Abstract.  The  role  of  software  ecosystems  in  the  development  and  evo¬ 
lution  of  open  architecture  systems  has  received  insufficient  consider¬ 
ation.  Such  systems  are  composed  of  heterogeneously-licensed  compo¬ 
nents,  open  source  or  proprietary  or  both,  in  an  architecture  in  which 
evolution  can  occur  by  evolving  existing  components  or  by  replacing 
them.  The  software  licenses  of  the  components  both  facilitate  and  con¬ 
strain  the  system’s  ecosystem,  and  the  rights  and  duties  of  the  licenses  are 
crucial  in  producing  an  acceptable  system.  We  discuss  software  ecosys¬ 
tems  of  open  architecture  systems  from  the  perspective  of  an  architect 
or  an  acquisition  organization,  and  outline  how  our  automated  tool  and 
environment  help  address  their  challenges,  support  reuse,  and  assist  in 
managing  coevolution  and  component  interdependence. 


1  Introduction 

A  substantial  number  of  development  organizations  are  adopting  a  strategy  in 
which  a  software-intensive  system  is  developed  with  an  open  architecture  (OA) 
[1],  whose  components  may  be  open  source  software  (OSS)  or  proprietary  with 
open  application  programming  interfaces  (APIs).  Such  systems  evolve  not  only 
through  the  evolution  of  their  individual  components,  but  also  through  replace¬ 
ment  of  one  component  by  another,  possibly  from  a  different  producer  or  under 
a  different  license.  With  this  approach,  the  organization  becomes  an  integrator 
of  components  largely  produced  elsewhere,  connected  with  shims  as  necessary  to 
achieve  the  desired  result.  An  OA  development  process  results  in  an  ecosystem 
in  which  the  integrator  is  influenced  from  one  direction  by  the  goals,  interfaces, 
license  choices,  and  release  cycles  of  the  component  producers,  and  in  another 
direction  by  the  needs  of  its  consumers.  As  a  result  the  software  components 
are  reused  more  widely,  and  the  resulting  OA  systems  can  achieve  reuse  benefits 
such  as  reduced  costs,  increased  reliability,  and  potentially  increased  agility  in 
evolving  to  meet  changing  needs.  An  emerging  challenge  is  to  realize  the  benefits 
of  this  approach  when  the  individual  components  are  heterogeneously  licensed, 
each  potentially  with  a  different  license,  rather  than  a  single  OSS  license  as  in 
uniformly-licensed  OSS  projects  or  a  single  proprietary  license  as  in  proprietary 
development. 
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This  challenge  is  inevitably  entwined  with  the  software  ecosystems  that  arise 
for  OA  systems.  We  find  that  an  OA  software  ecosystem  involves  organizations 
and  individuals  producing  and  consuming  components,  and  supply  paths  from 
producer  to  consumer;  but  also 

—  the  OA  of  the  system(s)  in  question, 

—  the  open  interfaces  met  by  the  components, 

—  the  degree  of  coupling  in  the  evolution  of  related  components,  and 

—  the  rights  and  obligations  resulting  from  the  software  licenses  under  which 
various  components  are  released,  that  propagate  from  producers  to  con¬ 
sumers. 


Producers 


Components 


Integrators 


OA  Systems 


System 

Consumers 


Mozilla 

Foundation 
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Fig.  1.  A  hypothetical  ecosystem  in  which  OA  systems  are  developed 


In  order  to  most  effectively  use  an  OA  approach  in  developing  and  evolving 
a  system,  it  is  essential  to  consider  this  OA  ecosystem.  An  OA  system  draws 
on  components  from  proprietary  vendors  and  open  source  projects.  Its  archi¬ 
tecture  is  made  possible  by  the  existing  general  ecosystem  of  producers,  from 
which  the  initial  components  are  chosen.  The  choice  of  a  specific  OA  begins 
a  specialized  software  ecosystem  involving  components  that  meet  (or  can  be 
shimmed  to  meet)  the  open  interfaces  used  in  the  architecture.  We  do  not  claim 
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this  is  the  best  or  the  only  way  to  reuse  components  or  produce  systems,  but 
it  is  an  ever  more  widespread  way.  In  this  paper  we  build  on  previous  work  on 
heterogeneously-licensed  systems  [2-4]  by  examining  how  OA  development  af¬ 
fects  and  is  affected  by  software  ecosystems,  and  the  role  of  component  licenses 
in  OA  software  ecosystems. 

A  motivating  example  of  this  approach  is  the  Unity  game  development  tool, 
produced  by  Unity  Technologies  [5].  Its  license  agreement,  from  which  we  quote 
below,  lists  eleven  distinct  licenses  and  indicates  the  tool  is  produced,  apparently 
using  an  OA  approach,  using  at  least  18  externally  produced  components  or 
groups  of  components: 

1.  The  Mono  Class  Library,  Copyright  2005-2008  Novell,  Inc. 

2.  The  Mono  Runtime  Libraries,  Copyright  2005-2008  Novell,  Inc. 

3.  Boo,  Copyright  2003-2008  Rodrigo  B.  Oliveira 

4.  UnityScript,  Copyright  2005-2008  Rodrigo  B.  Oliveira 

5.  OpenAL  cross  platform  audio  library,  Copyright  1999-2006  by  authors. 

6.  PhysX  physics  library.  Copyright  2003-2008  by  Ageia  Technologies,  Inc. 

7.  libvorbis.  Copyright  (c)  2002-2007  Xiph.org  Foundation 

8.  libtheora.  Copyright  (c)  2002-2007  Xiph.org  Foundation 

9.  zlib  general  purpose  compression  library.  Copyright  (c)  1995-2005  Jean-loup 
Gailly  and  Mark  Adler 

10.  libpng  PNG  reference  library 

11.  jpeglib  JPEG  library.  Copyright  (C)  1991-1998,  Thomas  G.  Lane. 

12.  Twilight  Prophecy  SDK,  a  multi-platform  development  system  for  virtual  reality 
and  multimedia.  Copyright  1997-2003  Twilight  3D  Finland  Oy  Ltd 

13.  dynamic_bitset,  Copyright  Chuck  Allison  and  Jeremy  Siek  2001-2002. 

14.  The  Mono  C#  Compiler  and  Tools,  Copyright  2005-2008  Novell,  Inc. 

15.  libcurl.  Copyright  (c)  1996-2008,  Daniel  Stenberg  <daniel@haxx.se>. 

16.  PostgreSQL  Database  Management  System 

17.  FreeType.  Copyright  (c)  2007  The  FreeType  Project  (www.freetype.org). 

18.  NVIDIA  Cg.  Copyright  (c)  2002-2008  NVIDIA  Corp. 

An  OA  system  can  evolve  by  a  number  of  distinct  mechanisms,  some  of  which 
are  common  to  all  systems  but  others  of  which  are  a  result  of  heterogeneous 
component  licenses  in  a  single  system. 

By  component  evolution  One  or  more  components  can  evolve,  altering  the 
overall  system’s  characteristics. 

By  component  replacement  One  or  more  components  may  be  replaced 
by  others  with  different  behaviours  but  the  same  interface,  or  with  a  different 
interface  and  the  addition  of  shim  code  to  make  it  match. 

By  architecture  evolution  The  OA  can  evolve,  using  the  same  components 
but  in  a  different  configuration,  altering  the  system’s  characteristics.  For  exam¬ 
ple,  as  discussed  in  Section  4,  changing  the  configuration  in  which  a  component 
is  connected  can  change  how  its  license  affects  the  rights  and  obligations  for  the 
overall  system. 

By  component  license  evolution  The  license  under  which  a  component 
is  available  may  change,  as  for  example  when  the  license  for  the  Mozilla  core 
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components  was  changed  from  the  Mozilla  Public  License  (MPL)  to  the  current 
Mozilla  Disjunctive  Tri-License;  or  the  component  may  be  made  available  under 
a  new  version  of  the  same  license,  as  for  example  when  the  GNU  General  Public 
License  (GPL)  version  3  was  released. 

By  a  change  to  the  desired  rights  or  acceptable  obligations  The  OA 

system’s  integrator  or  consumers  may  desire  additional  license  rights  (for  exam¬ 
ple  the  right  to  sublicense  in  addition  to  the  right  to  distribute),  or  no  longer 
desire  specific  rights;  or  the  set  of  license  obligations  they  find  acceptable  may 
change.  In  either  case  the  OA  system  evolves,  whether  by  changing  components, 
evolving  the  architecture,  or  other  means,  to  provide  the  desired  rights  within 
the  scope  of  the  acceptable  obligations.  For  example,  they  may  no  longer  be  will¬ 
ing  or  able  to  provide  the  source  code  for  components  within  the  reciprocality 
scope  of  a  GPL-licensed  module. 

The  interdependence  of  integrators  and  producers  results  in  a  co-evolution  of 
software  within  an  OA  ecosystem.  Producers  may  manage  their  evolution  with 
a  loose  coordination  among  releases,  for  example  as  between  the  Gnome  and 
Mozilla  organizations.  Releases  of  producer  components  create  a  tension  through 
the  ecosystem  relationships  with  the  releases  of  OA  systems  using  those  compo¬ 
nents,  as  integrators  accomodate  the  choices  of  available,  supported  components 
with  their  own  goals  and  needs.  As  discussed  in  our  previous  work  [4],  license 
rights  and  obligations  are  manifested  at  each  component’s  interface,  then  medi¬ 
ated  through  the  system’s  OA  to  entail  the  rights  and  corresponding  obligations 
for  the  system  as  a  whole.  As  a  result,  integrators  must  frequently  re-evaluate 
an  OA  system’s  rights  and  obligations.  In  contrast  to  homogeneously-licensed 
systems,  license  change  across  versions  is  a  characteristic  of  OA  ecosystems,  and 
architects  of  OA  systems  require  tool  support  for  managing  the  ongoing  licensing 
changes. 

We  propose  that  such  support  must  have  several  characteristics. 

—  It  must  rest  on  a  license  structure  of  rights  and  obligations  (Section  5), 
focusing  on  obligations  that  are  enactable  and  testable.  For  example,  many 
OSS  licenses  include  an  obligation  to  make  a  component’s  modified  code 
public,  and  whether  a  specific  version  of  the  code  is  public  at  a  specified 
Web  address  is  both  enactable  (it  can  be  put  into  practice)  and  testable.  In 
contrast,  the  GPL  v.3  provision  “No  covered  work  shall  be  deemed  part  of  an 
effective  technological  measure  under  any  applicable  law  fulfilling  obligations 
under  article  11  of  the  WIPO  copyright  treaty”  is  not  enactable  in  any 
obvious  way,  nor  is  it  testable  —  how  can  one  verify  what  others  deem? 

—  It  must  take  account  of  the  distinctions  between  the  design-time,  build¬ 
time,  and  distribution-time  architectures  (Sections  4,  5,  6)  and  the  rights 
and  obligations  that  come  into  play  for  each  of  them. 

—  It  must  distinguish  the  architectural  constructs  significant  for  software  li¬ 
censes,  and  embody  their  effects  on  rights  and  obligations  (Section  4). 

—  It  must  define  license  architectures  (Section  6). 

—  It  must  provide  an  automated  environment  for  creating  and  managing  li¬ 
cense  architectures.  We  are  developing  a  prototype  that  manages  a  license 
architecture  as  a  view  of  its  system  architecture  [4] . 
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—  Finally,  it  must  automate  calculations  on  system  rights  and  obligations  so 
that  they  may  be  done  easily  and  frequently,  whenever  any  of  the  factors 
affecting  rights  and  obligations  may  have  changed  (Section  7). 

In  the  remainder  of  this  paper,  we  survey  some  related  work  (Section  2), 
provide  an  overview  of  OSS  licenses  and  projects  (Section  3),  define  and  discuss 
characteristics  of  open  architectures  (Section  4),  introduce  a  structure  for  licenses 
(Section  5),  outline  license  architectures  (Section  6),  sketch  our  approach  for 
license  analysis  (Section  7),  and  conclude  (Section  8). 

2  Related  Work 

Jansen  et  al.  discuss  the  perspective  of  software  vendors  on  software  ecosystems 

[6] .  Scacchi  examines  how  free/open  source  software  projects  become  part  of  a 
multi-project  ecosystem,  interdependent  in  the  context  of  evolution  and  reuse 

[7]  .  The  present  work  examines  the  point  of  view  of  organizations  that  develop 
or  acquire  OA  systems. 

Brown  and  Booch  discuss  issues  that  arise  in  the  reuse  of  OSS  components, 
such  as  that  interdependence  causes  changes  to  propagate,  and  versions  of  the 
components  evolve  asynchronously  giving  rise  to  co-evolution  of  interrelated  code 
in  the  OA  [8].  If  the  components  evolve,  the  OA  system  itself  is  evolving.  The 
evolution  can  also  include  changes  to  the  licenses,  and  the  licenses  can  change 
from  version  to  version. 

Ven  and  Mannaert  discuss  the  challenges  independent  software  vendors  face 
in  combining  OSS  and  proprietary  components,  with  emphasis  on  how  OSS 
components  evolve  and  are  maintained  in  this  context  [9]. 

Scacchi  and  Alspaugh  examine  the  features  of  software  architecture  and  OSS 
licenses  that  affect  the  success  of  an  OA  strategy  [3]. 

There  are  a  number  of  discussions  of  OSS  licenses,  such  as  Rosen  [10]  and 
Fontana  et  al.  [11]. 

3  Open-Source  Software  (OSS) 

Traditional  proprietary  licenses  allow  a  company  to  retain  control  of  software  it 
produces,  and  restrict  the  access  and  rights  that  outsiders  can  have.  OSS  licenses, 
on  the  other  hand,  are  designed  to  encourage  sharing  and  reuse  of  software, 
and  grant  access  and  as  many  rights  as  possible.  OSS  licenses  are  classified  as 
academic  or  reciprocal  Academic  OSS  licenses  such  as  the  Berkeley  Software 
Distribution  (BSD)  license,  the  Massachusetts  Institute  of  Technology  license, 
the  Apache  Software  License,  and  the  Artistic  License,  grant  nearly  all  rights 
to  components  and  their  source  code,  and  impose  few  obligations.  Anyone  can 
use  the  software,  create  derivative  works  from  it,  or  include  it  in  proprietary 
projects.  Typical  academic  obligations  are  simply  to  not  remove  the  copyright 
and  license  notices. 
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Reciprocal  OSS  licenses  take  a  more  active  stance  towards  sharing  and  reusing 
software  by  imposing  the  obligation  that  reciprocally-licensed  software  not  be 
combined  (for  various  definitions  of  “combined”)  with  any  software  that  is  not 
in  turn  also  released  under  the  reciprocal  license.  The  goals  are  to  increase  the 
domain  of  OSS  by  encouraging  developers  to  bring  more  components  under  its 
aegis,  and  to  prevent  improvements  to  OSS  components  from  vanishing  behind 
proprietary  licenses.  Example  reciprocal  licenses  are  GPL,  the  Mozilla  Public 
License  (MPL),  and  the  Common  Public  License, 

Both  proprietary  and  OSS  licenses  typically  disclaim  liability,  assert  no  war¬ 
ranty  is  implied,  and  obligate  licensees  to  not  use  the  licensor’s  name  or  trade¬ 
marks.  Newer  licenses  often  cover  patent  issues  as  well,  either  giving  a  restricted 
patent  license  or  explicitly  excluding  patent  rights. 

The  Mozilla  Disjunctive  Tri-License  licenses  the  core  Mozilla  components 
under  any  one  of  three  licenses  (MPL,  GPL,  or  the  GNU  Lesser  General  Public 
License  LGPL);  OSS  developers  can  choose  the  one  that  best  suits  their  needs 
for  a  particular  project  and  component. 

The  Open  Source  Initiative  (OSI)  maintains  a  widely-respected  definition  of 
“open  source”  and  gives  its  approval  to  licenses  that  meet  it  [12].  OSI  maintains 
and  publishes  a  repository  of  approximately  70  approved  OSS  licenses. 

Common  practice  has  been  for  an  OSS  project  to  choose  a  single  license 
under  which  all  its  products  are  released,  and  to  require  developers  to  contribute 
their  work  only  under  conditions  compatible  with  that  license.  For  example,  the 
Apache  Contributor  License  Agreement  grants  enough  of  each  author’s  rights 
to  the  Apache  Software  Foundation  for  the  foundation  to  license  the  resulting 
systems  under  the  Apache  Software  License.  This  sort  of  rights  regime,  in  which 
the  rights  to  a  system’s  components  are  homogenously  granted  and  the  system 
has  a  single  well-defined  OSS  license,  was  the  norm  in  the  early  days  of  OSS  and 
continues  to  be  practiced. 

4  Open  Architecture  (OA) 

Open  architecture  (OA)  software  is  a  customization  technique  introduced  by 
Oreizy  [1]  that  enables  third  parties  to  modify  a  software  system  through  its 
exposed  architecture,  evolving  the  system  by  replacing  its  components.  Increas¬ 
ingly  more  software-intensive  systems  are  developed  using  an  OA  strategy,  not 
only  with  OSS  components  but  also  proprietary  components  with  open  APIs 
(e.g.  [5]).  Using  this  approach  can  lower  development  costs  and  increase  relia¬ 
bility  and  function  [3] .  Composing  a  system  with  heterogeneously-licensed  com¬ 
ponents,  however,  increases  the  likelihood  of  conflicts,  liabilities,  and  no-rights 
stemming  from  incompatible  licenses.  Thus,  in  our  work  we  define  an  OA  sys¬ 
tem  as  a  software  system  consisting  of  components  that  are  either  open  source 
or  proprietary  with  open  API,  whose  overall  system  rights  at  a  minimum  allow 
its  use  and  redistribution,  in  full  or  in  part. 

It  may  appear  that  using  a  system  architecture  that  incorporate  OSS  com¬ 
ponents  and  uses  open  APIs  will  result  in  an  OA  system.  But  not  all  such 
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architectures  will  produce  an  OA,  since  the  (possibly  empty)  set  of  available 
license  rights  for  an  OA  system  depends  on:  (a)  how  and  why  OSS  and  open 
APIs  are  located  within  the  system  architecture,  (b)  how  OSS  and  open  APIs 
are  implemented,  embedded,  or  interconnected,  and  (c)  the  degree  to  which  the 
licenses  of  different  OSS  components  encumber  all  or  part  of  a  software  system’s 
architecture  into  which  they  are  integrated  [3,13]. 

The  following  kinds  of  software  elements  appearing  in  common  software  ar¬ 
chitectures  can  affect  whether  the  resulting  systems  are  open  or  closed  [14]. 

Software  source  code  components — These  can  be  either  (a)  standalone 
programs,  (b)  libraries,  frameworks,  or  middleware,  (c)  inter-application  script 
code  such  as  C  shell  scripts,  or  (d)  intra-application  script  code,  as  for  creating 
Rich  Internet  Applications  using  domain-specific  languages  such  as  XUL  for  the 
Firefox  Web  browser  [15]  or  “mashups”  [16].  Their  source  code  is  available  and 
they  can  be  rebuilt.  Each  may  have  its  own  distinct  license. 

Executable  components — These  components  are  in  binary  form,  and  the 
source  code  may  not  be  open  for  access,  review,  modification,  or  possible  redis¬ 
tribution  [10].  If  proprietary,  they  often  cannot  be  redistributed,  and  so  such 
components  will  be  present  in  the  design-  and  run-time  architectures  but  not  in 
the  distribution-time  architecture. 

Software  services — An  appropriate  software  service  can  replace  a  source 
code  or  executable  component. 

Application  programming  interfaces/ APIs — Availability  of  externally 
visible  and  accessible  APIs  is  the  minimum  requirement  for  an  “open  system” 
[17].  APIs  are  not  and  cannot  be  licensed,  and  can  limit  the  propagation  of 
license  obligations. 

Software  connectors — Software  whose  intended  purpose  is  to  provide  a 
standard  or  reusable  way  of  communication  through  common  interfaces,  e.g. 
High  Level  Architecture  [18],  CORBA,  MS  .NET,  Enterprise  Java  Beans,  and 
GNU  Lesser  General  Public  License  (LGPL)  libraries.  Connectors  can  also  limit 
the  propagation  of  license  obligations. 

Methods  of  connection  These  include  linking  as  part  of  a  configured  sub¬ 
system,  dynamic  linking,  and  client-server  connections.  Methods  of  connection 
affect  license  obligation  propagation,  with  different  methods  affecting  different 
licenses. 

Configured  system  or  subsystem  architectures — These  are  software 
systems  that  are  used  as  atomic  components  of  a  larger  system,  and  whose  in¬ 
ternal  architecture  may  comprise  components  with  different  licenses,  affecting 
the  overall  system  license.  To  minimize  license  interaction,  a  configured  sys¬ 
tem  or  sub-architecture  may  be  surrounded  by  what  we  term  a  license  firewall , 
namely  a  layer  of  dynamic  links,  client-server  connections,  license  shims,  or  other 
connectors  that  block  the  propagation  of  reciprocal  obligations. 

Figure  2  shows  a  high-level  view  of  a  reference  architecture  that  includes 
all  the  kinds  of  software  elements  listed  above.  This  reference  architecture  has 
been  instantiated  in  a  number  of  configured  systems  that  combine  OSS  and 
closed  source  components.  One  such  system  handles  time  sheets  and  payroll 
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at  our  university;  another  implements  the  web  portal  for  a  university  research 
lab  (http://proxy.arts.uci.edu/gamelab/).  The  configured  systems  consist 
of  software  components  such  as  a  Mozilla  Web  browser,  Gnome  Evolution  email 
client,  and  WordPerfect  word  processor,  all  running  on  a  Linux  operating  system 
accessing  file,  print,  and  other  remote  networked  servers  such  as  an  Apache  Web 
server.  Components  are  interconnected  through  a  set  of  software  connectors  that 
bridge  the  interfaces  of  components  and  combine  the  provided  functionality  into 
the  system’s  services. 

5  Software  Licenses 

Copyright  law  is  the  common  basis  for  software  licenses,  and  gives  the  original 
author  of  a  work  certain  exclusive  rights:  the  rights  to  use,  copy,  modify,  merge, 
publish,  distribute,  sub-license,  and  sell  copies.  The  author  may  license  these 
rights,  individually  or  in  groups,  to  others;  the  license  may  give  a  right  either 
exclusively  or  non-exclusively.  After  a  period  of  years,  copyright  rights  enter  the 
public  domain.  Until  then  copyright  may  only  be  obtained  through  licensing. 

Licenses  typically  impose  obligations  that  must  be  met  in  order  for  the  li¬ 
censee  to  realize  the  assigned  rights.  Common  obligations  include  the  obligation 
to  publish  at  no  cost  any  source  code  you  modify  (MPL)  or  the  reciprocal  obliga¬ 
tion  to  publish  all  source  code  included  at  build-time  or  statically  linked  (GPL). 
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Fig.  3.  Instance  architecture  for  a  heterogeneously-licensed  e-business  system 


The  obligations  may  conflict,  as  when  a  GPL’d  component’s  reciprocal  obligation 
to  publish  source  code  of  other  components  is  combined  with  a  proprietary  com¬ 
ponent’s  license  prohibition  of  publishing  its  source  code.  In  this  case,  no  rights 
may  be  available  for  the  system  as  a  whole,  not  even  the  right  of  use,  because 
the  two  obligations  cannot  simultaneously  be  met  and  thus  neither  component 
can  be  used  as  part  of  the  system. 

The  basic  relationship  between  software  license  rights  and  obligations  can  be 
summarized  as  follows:  if  the  specified  obligations  are  met,  then  the  correspond¬ 
ing  rights  are  granted.  For  example,  if  you  publish  your  modified  source  code 
and  sub-licensed  derived  works  under  MPL,  then  you  get  all  the  MPL  rights  for 
both  the  original  and  the  modified  code.  However,  license  details  are  complexm 
subtle,  and  difficult  to  comprehend  and  track — it  is  easy  to  become  confused  or 
make  mistakes.  The  challenge  is  multiplied  when  dealing  with  configured  system 
architectures  that  compose  a  large  number  of  components  with  heterogeneous 
licenses,  so  that  the  need  for  legal  counsel  begins  to  seem  inevitable  [10, 11]. 

We  have  developed  an  approach  for  expressing  software  licenses  that  is  more 
formal  and  less  ambiguous  than  natural  language,  and  that  allows  us  to  cal¬ 
culate  and  identify  conflicts  arising  from  the  rights  and  obligations  of  two  or 
more  component’s  licenses.  Our  approach  is  based  on  Hohfeld’s  classic  group  of 
eight  fundamental  jural  relations  [19],  of  which  we  use  right ,  duty ,  no-right ,  and 
privilege.  We  start  with  a  tuple  <actor,  operation,  action,  object>  for  expressing 


42 


!  Web  Browser 

I  Email  &  Calendar 

!  Word  Processor ! ! 

User  Interface 

i  User  Interface 

User  Interface  1 

:  t  : 

Connector  1 

1  Connector  2  : 

1  Connector  3  1 

:  :  : 


1  Protocol  j ' 

t 

Red  Hat  /  i 

_ i _ 

Free 

Apache 

Software 

Foundation  j 

i  Foundation; 

Local 

Server 


Fig.  4.  Reference  architecture  components  supplied  by  an  organization,  indicating  the 
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a  right  or  obligation.  The  actor  is  the  “licensee”  for  all  the  licenses  we  have 
examined.  The  operation  is  one  of  the  following:  “may”,  “must”,  “must  not”, 
or  “need  not”,  with  “may”  and  “need  not”  expressing  rights  and  “must”  and 
“must  not”  expressing  obligations.  Because  copyright  rights  are  only  available  to 
entities  who  have  been  granted  a  sublicense,  only  the  listed  rights  are  available, 
and  the  absence  of  a  right  means  that  it  is  not  available.  The  action  is  a  verb  or 
verb  phrase  describing  what  may,  must,  must  not,  or  need  not  be  done,  with  the 
object  completing  the  description.  A  license  may  be  expressed  as  a  set  of  rights, 
with  each  right  associated  with  zero  or  more  obligations  that  must  be  fulfilled 
in  order  to  enjoy  that  right.  Figure  5  displays  the  tuples  and  associations  for 
two  of  the  rights  and  their  associated  obligations  for  the  academic  BSD  software 
license.  Note  that  the  first  right  is  granted  without  corresponding  obligations. 

Heterogeneously-licensed  system  designers  have  developed  a  number  heuris¬ 
tics  to  guide  architectural  design  while  avoiding  some  license  conflicts.  First,  it  is 
possible  to  use  a  reciprocally-licenced  component  through  a  license  firewall  that 
limits  the  scope  of  reciprocal  obligations.  Rather  than  connecting  conflicting 
components  directly  through  static  or  other  build-time  links,  the  connection  is 
made  through  a  dynamic  link,  client-server  protocol,  license  shim  (such  as  a  Lim¬ 
ited  General  Public  License  connector),  or  run-time  plug-ins.  A  second  approach 
used  by  a  number  of  large  organizations  is  simply  to  avoid  using  any  reciprocally- 
licensed  components.  A  third  approach  is  to  meet  the  license  obligations  (if  that 
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<Licensee,  may,  use,  the  binary  form  of  COMPONENTS 


Fig.  5.  Tuples  for  some  rights  and  obligations  of  the  BSD  license 


is  possible)  by  for  example  retaining  copyright  and  license  notices  in  the  source 
and  publishing  the  source  code.  However,  even  using  design  heuristics  such  as 
these  (and  there  are  many),  keeping  track  of  license  rights  and  obligations  across 
components  that  are  interconnected  in  complex  OAs  quickly  becomes  too  cum¬ 
bersome.  Thus,  automated  support  is  needed  to  manage  the  multi-component, 
multi-license  complexity. 


6  License  Architectures 

Our  license  model  forms  a  basis  for  effective  reasoning  about  licenses  in  the  con¬ 
text  of  actual  systems,  and  calculating  the  resulting  rights  and  obligations.  In 
order  to  do  so,  we  need  a  certain  amount  of  information  about  the  system’s  con¬ 
figuration  at  design-,  build-,  distribution-,  and  run-time.  The  needed  information 
comprises  the  license  architecture,  an  abstraction  of  the  system  architecture: 

1.  the  set  of  components  of  the  system; 

2.  the  relation  mapping  each  component  to  its  license; 

3.  the  relation  mapping  each  component  to  its  set  of  sources;  and 

4.  the  relation  from  each  component  to  the  set  of  components  in  the  same 
license  scope,  for  each  license  for  which  “scope”  is  defined  (e.g.  GPL),  and 
from  each  source  to  the  set  of  sources  of  components  in  the  scope  of  its 
component. 


Fig.  6.  The  license  architecture  metamodel 
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With  this  information  and  definitions  of  the  licenses  involved,  we  can  calcu¬ 
late  rights  and  obligations  for  individual  components  or  for  the  entire  system, 
and  guide  heterogeneously- licensed  system  design. 

7  License  Analysis 

Given  a  formal  specification  of  a  software  system’s  architecture,  we  can  asso¬ 
ciate  software  license  attributes  with  the  system’s  components,  connectors,  and 
sub-system  architectures,  resulting  in  a  license  architecture  for  the  system,  and 
calculate  the  copyright  rights  and  obligations  for  the  system’s  configuration.  Due 
to  the  complexity  of  license  architecture  analysis,  and  the  need  to  re-analyze  ev¬ 
ery  time  a  component  evolves,  a  component’s  license  changes,  a  component  is 
substituted,  or  the  system  architecture  changes,  OA  integrators  really  need  an 
automated  license  architecture  analysis  environment.  We  are  developing  a  pro¬ 
totype  of  such  an  environment  [4] . 

We  use  an  architectural  description  language  specified  in  xADL  [20]  to  de¬ 
scribe  OAs  that  can  be  designed  and  analyzed  with  a  software  architecture  design 
environment  [21],  such  as  ArchStudio4  [22].  We  have  built  the  Software  Archi¬ 
tecture  License  Analysis  module  on  top  of  ArchStudio’s  Traceability  View  [23]. 
This  allows  for  the  specification  of  licenses  as  a  list  of  attributes  (license  tuples) 
using  a  form-based  user  interface  in  ArchStudio4  [21,22]. 


£  Outlne  S3 

■  /architectures/hd.xml 

&  Acbvty  Diagrams 
&  Statecharts 
=  IS’  Structures 

3?  main 

3?  MoZila  SubArch 
S  &  Types 

3  &  Component  Types 
ID  MoZBaComp 
&  Connector  Types 
&  Interface  Types 


Fig.  7.  Automated  tool  performing  license  analysis  of  instance  architecture  (version 
information  not  shown) 


We  analyze  rights  and  obligations  as  described  below  [4]. 
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7.1  Propagation  of  reciprocal  obligations 

We  follow  the  widely-accepted  interpretation  that  build-time  static  linkage  prop¬ 
agate  the  reciprocal  obligations,  but  appropriate  license  firewalls  do  not.  Analysis 
begins,  therefore,  by  propagating  these  obligations  along  all  connectors  that  are 
not  license  firewalls. 


7.2  Obligation  conflicts 

An  obligation  can  conflict  with  another  obligation,  or  with  the  set  of  available 
rights,  by  requiring  a  copyright  right  that  has  not  been  granted.  For  instance,  a 
proprietary  license  may  require  that  a  licensee  must  not  redistribute  source  code, 
but  GPL  states  that  a  licensee  must  redistribute  source  code.  Thus,  the  conflict 
appears  in  the  modality  of  the  two  otherwise  identical  obligations,  “must  not” 
in  the  proprietary  license  and  “must”  in  GPL. 


7.3  Rights  and  obligations  calculations 

The  rights  available  for  the  entire  system  (use,  copy,  modify,  etc.)  are  calcu¬ 
lated  as  the  intersection  of  the  sets  of  rights  available  for  each  component  of  the 
system.  If  a  conflict  is  found  involving  the  obligations  and  rights  of  linked  com¬ 
ponents,  it  is  possible  for  the  system  architect  to  consider  an  alternative  linking 
scheme,  e.g.  using  one  or  more  connectors  along  the  paths  between  the  compo¬ 
nents  that  act  as  a  license  firewall.  This  means  that  the  architecture  and  the 
automated  environment  together  can  determine  what  OA  design  best  meets  the 
problem  at  hand  with  available  software  components.  Components  with  conflict¬ 
ing  licenses  do  not  need  to  be  arbitrarily  excluded,  but  instead  may  expand  the 
range  of  possible  architectural  alternatives  if  the  architect  seeks  such  flexibility 
and  choice. 


8  Conclusion 

This  paper  discusses  the  role  of  ecosystems  in  the  development  and  evolution 
of  OA  systems.  License  rights  and  obligations  play  a  key  role  in  how  and  why 
an  OA  system  evolves  in  its  ecosystem.  We  note  that  license  changes  across 
versions  of  components  is  a  characteristic  of  OA  systems  and  ecosystems.  A 
structure  for  modeling  software  licenses  and  the  license  architecture  of  a  system 
and  automated  support  for  calculating  its  rights  and  obligations  are  needed  in 
order  to  manage  a  system’s  evolution  in  the  context  of  its  ecosystem.  We  have 
outlined  an  approach  for  achieving  these  and  sketched  how  they  further  the  goal 
of  reusing  components  in  developing  software-intensive  systems.  Much  more  work 
remains  to  be  done,  but  we  believe  this  approach  turns  a  vexing  problem  into 
one  for  which  workable  solutions  can  be  obtained. 
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